-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(tiller): Supersede multiple deployments #3539
Conversation
Use same naming as the rest of the file.
- Add logging - Verify other release names not changed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really liked how you improved the variable names to make it more clear on what behaviour changed. LGTM!
slating for v2.8.2 |
Agreed -- so much more clear |
@bacongobbler @stealthybox sure thing, it was mainly for myself to be able to be follow what was happening :) |
I believe the issue applies to |
* add test for rolling back from a FAILED deployment * Update naming of release variables Use same naming as the rest of the file. * Update rollback test - Add logging - Verify other release names not changed * fix(tiller): Supersede multiple deployments There are cases when multiple revisions of a release has been marked with DEPLOYED status. This makes sure any previous deployment will be set to SUPERSEDED when doing rollbacks. Closes #2941 #3513 #3275 (cherry picked from commit 5f1a21b)
Solves helm#3722 by making the changes in helm#3539 more compatible with the previous behavior. This gives a recovery option for "oops I deleted my helm release" by allowing rollback, which is intended to be a working feature of helm. Note that purging releases removes the history required to rollback, so this doesn't work in that case. However, purging takes significantly more time, so it's harder to accidentally purge everything. Signed-off-by: Brent bmperrea@gmail.com
Solves helm#3722 by making the changes in helm#3539 more compatible with the previous behavior. This gives a recovery option for "oops I deleted my helm release" by allowing rollback, which is intended to be a working feature of helm. Note that purging releases removes the history required to rollback, so this doesn't work in that case. However, purging takes significantly more time, so it's harder to accidentally purge everything. Signed-off-by: Brent Perreault <bmperrea@gmail.com>
Solves helm#3722 by making the changes in helm#3539 more compatible with the previous behavior. This gives a recovery option for "oops I deleted my helm release" by allowing rollback, which is intended to be a working feature of helm. Note that purging releases removes the history required to rollback, so this doesn't work in that case. However, purging takes significantly more time, so it's harder to accidentally purge everything. Signed-off-by: Brent <bmperrea@gmail.com>
Solves #3722 by making the changes in #3539 more compatible with the previous behavior. This gives a recovery option for "oops I deleted my helm release" by allowing rollback, which is intended to be a working feature of helm. Note that purging releases removes the history required to rollback, so this doesn't work in that case. However, purging takes significantly more time, so it's harder to accidentally purge everything. Signed-off-by: Brent <bmperrea@gmail.com>
Solves helm#3722 by making the changes in helm#3539 more compatible with the previous behavior. This gives a recovery option for "oops I deleted my helm release" by allowing rollback, which is intended to be a working feature of helm. Note that purging releases removes the history required to rollback, so this doesn't work in that case. However, purging takes significantly more time, so it's harder to accidentally purge everything. Signed-off-by: Brent <bmperrea@gmail.com> Signed-off-by: Sebastien Plisson <sebastien.plisson@gmail.com>
* add test for rolling back from a FAILED deployment * Update naming of release variables Use same naming as the rest of the file. * Update rollback test - Add logging - Verify other release names not changed * fix(tiller): Supersede multiple deployments There are cases when multiple revisions of a release has been marked with DEPLOYED status. This makes sure any previous deployment will be set to SUPERSEDED when doing rollbacks. Closes helm#2941 helm#3513 helm#3275
Solves helm#3722 by making the changes in helm#3539 more compatible with the previous behavior. This gives a recovery option for "oops I deleted my helm release" by allowing rollback, which is intended to be a working feature of helm. Note that purging releases removes the history required to rollback, so this doesn't work in that case. However, purging takes significantly more time, so it's harder to accidentally purge everything. Signed-off-by: Brent <bmperrea@gmail.com> Signed-off-by: Sebastien Plisson <sebastien.plisson@gmail.com>
* add test for rolling back from a FAILED deployment * Update naming of release variables Use same naming as the rest of the file. * Update rollback test - Add logging - Verify other release names not changed * fix(tiller): Supersede multiple deployments There are cases when multiple revisions of a release has been marked with DEPLOYED status. This makes sure any previous deployment will be set to SUPERSEDED when doing rollbacks. Closes helm#2941 helm#3513 helm#3275
Solves helm#3722 by making the changes in helm#3539 more compatible with the previous behavior. This gives a recovery option for "oops I deleted my helm release" by allowing rollback, which is intended to be a working feature of helm. Note that purging releases removes the history required to rollback, so this doesn't work in that case. However, purging takes significantly more time, so it's harder to accidentally purge everything. Signed-off-by: Brent <bmperrea@gmail.com>
Solves helm#3722 by making the changes in helm#3539 more compatible with the previous behavior. This gives a recovery option for "oops I deleted my helm release" by allowing rollback, which is intended to be a working feature of helm. Note that purging releases removes the history required to rollback, so this doesn't work in that case. However, purging takes significantly more time, so it's harder to accidentally purge everything. Signed-off-by: Brent <bmperrea@gmail.com>
* add test for rolling back from a FAILED deployment * Update naming of release variables Use same naming as the rest of the file. * Update rollback test - Add logging - Verify other release names not changed * fix(tiller): Supersede multiple deployments There are cases when multiple revisions of a release has been marked with DEPLOYED status. This makes sure any previous deployment will be set to SUPERSEDED when doing rollbacks. Closes helm#2941 helm#3513 helm#3275
There are cases when multiple revisions of a release has been marked with DEPLOYED status. This makes sure any previous deployment will be set to SUPERSEDED when doing rollbacks.
The original unit test was updated by @bacongobbler and cherry picked from d05bc61.
(hopefully) Closes #2941 #3513 #3275