fix: allow stopping of failed and pending helm releases

@roman_pertl

Thank you for your contributions to GitLab. We believe that everyone can contribute and contributions like yours are what make GitLab great!

Our Merge Request coaches will ensure your contribution is reviewed in a timely manner. To learn more about the merge request triage process you can refer to the Wider Community Merge Request Triage page.

To bring your merge request to the attention of the relevant team within GitLab, you can ask our bot to label it with a group label. For example, if your merge request changes a project management feature, it can be labelled by commenting @gitlab-bot label ~"group::project management". To find the most relevant group for your change, you can look up the group based on the most relevant product category in the product categories table. Once you have found the group name, type @gitlab-bot label ~group::, then start to type the group name and select the applicable group label, then submit the comment and the bot will apply the label for you.

If after a few days, there's no message from a GitLab team member, feel free to ping @gitlab-org/coaches or ask for help by commenting @gitlab-bot help.

These resources may help you to move your Merge Request to the next steps:

This message was generated automatically. You're welcome to improve it.

added Community contribution label

added 1st contribution label

requested review from @hfyngvason

assigned to @hfyngvason

added Category:Auto DevOps backend labels

Thanks @roman_pertl This is great

I made a couple of small comments on the code, but in addition I'm wondering:

Should this perhaps be a fix instead of a feat? The rationale being that if failed review app deployments cannot be deleted, then that is a ~bug.
Would you be willing to add a test for this behavior? Something like test-delete and test-delete-postgresql, but with an intentionally failed release.

Let me know what you think

mentioned in issue gitlab-org/quality/triage-reports#3758 (closed)

Setting label(s) ~"devops::configure" ~"group::configure" sectionops based on Category:Auto DevOps ~"group::configure".

added devopsconfigure [DEPRECATED] groupconfigure [DEPRECATED] sectionops labels

added 1 commit

6517d8c5 - fix: allow stopping of failed and pending helm releases

Compare with previous version

One additional comment. We might should also think about different states during deployment.

but to properly cover all cases, we would need to make additional changes depending on the state of the helm release

helm release state pending

If a helm release is in pending state, it could be that

another deployment is currently running
another deployed failed (e.g. was interrupted)

The upgrade will fail in this case anyway and the correct behavior would be to use helm rollback and then do the upgrade again.

helm release state failed

A release is marked as failed if the new release is not ready until the timeout (default 5 minutes) is reached. As we use the atomic option for upgrades anyway, failed releases will be rolled back anyway.