### Problem to solve CI/CD Environments might have a stop action defined, so a cleanup job is triggered when the Environment is stopped. While this **can** be done manually, it is triggered automatically if the [corresponding branch is deleted](https://gitlab.com/gitlab-org/gitlab-ce/blob/73c6477b/doc/ci/environments.md#L516-517). Users might want to stop Environments (deployments in this case), even productive ones **exclusively** on a **manual basis**, so the Environment lifecycle is independent from merging a branch. ### Intended users Unknown ### Further details * Even though this behavior is documented, it is imho unexpected that Environments are stopped automatically. * `on_stop` in `.gitlab_ci.yml` behaves as `on_stop_or_branch_remove` :wink: * Especially in smaller projects, common DEV/UAT environments might be prepared / defined in feature branches and should *survive* being merged after the MR got accepted by the responsible team members. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> ### Permissions and Security No need for changes. ### Documentation Currently, the `on_stop` action is responsible for defining a stop action and the current behavior. In order not to break the current behaviour, I would add an optional property `keep_running` to the `environment` block like ```yaml my deployment: stage: deploy script: make deploy-app environment: name: my-env on_stop: stop_app # if this is defined and set to 'true', the environment is not stopped # when its defining feature branch got removed keep_running: true ``` ### Testing The risk or drawback is to have the `.gitlab-ci.yml` syntax extended, which will require additional tests. ### What does success look like, and how can we measure that? **Success:** An environment is not stopped after its feature branch is deleted iff the `keep_running` property is defined on the environment and set to `true`. ### Links / references