Allow users to cleanup partial resources from failed deployments
This is based on the findings in Investigate solutions for `auto_stop_in` not en... (#429616 - closed)
Release notes
The Environment auto_stop_in
functionality was updated to run the job from the last finished pipeline, instead of the last successful pipeline. This avoid edge cases where the auto stop job can not run because of not having any successful pipelines.
This behaviour might be considered a breaking change in some situations. The new behaviour is currently behind a feature flag, and will become the default in 17.0, and at the same time, we are going to deprecate the old behaviour to be removed from GitLab in 18.0. We recommend everyone to start transitioning or to configure the feature flag immediately to minimize the risks of the breaking change at the first 17.x upgrade.
Problem
The Environment auto_stop_in
feature makes use of an AutoStopWorker
, which runs an Environment's stop jobs. The stop jobs of an Environment is extracted from the last successful pipeline. This becomes a problem when the pipelines are failing because it will either pick up the stop jobs of an old successful pipeline, or there will be no jobs picked up at all if there are no successful pipelines.
Please see the Problem Discussion Thread and Environment `auto_stop_in` doesn't engage when ... (#382549 - closed) for further details.
Solution
We have a few possible ways to resolve this problem, but ultimately we settled on changing the scope of an Environment's "stop actions" so that it picks up the jobs from the last finished pipeline. Finished means successful, cancelled, or failed.
This change will affect 1) how auto_stop_in
works, and 2) the Environment's stop actions as displayed on the UI.
Please see the Solutions Proposal Thread for more details. See this and this for comments indicating the solutions we settled on.
Solution Proof of Concept
POC: Extend Environment stop actions to include... (!139612 - closed)
Release Considerations
- This should be introduced behind a Feature Flag.
- The Feature Flag check in code should be per project, e.g.:
FeatureFlag.enable?(:feature_x, environment.project)
- The Feature Flag will be disabled by default and can be enabled per project
- Given that this is a major change in behavior, we should only start the Feature Flag rollout during %17.0 and enable it globally as part of the %17.0 release