Add support for multiple on_stop jobs with parallel:matrix: deployments
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
Problem to solve
Currently when using parallel:matrix to deploy to multiple environments, the on_stop job for such environments don't support stopping all the created environments. For example, when deploying with parallel:matrix using this job definition:
stages:
- deploy-review
deploy:review:
stage: deploy-review
parallel:
matrix:
- STACK: [app1, app2, monitoring]
environment:
name: $CI_COMMIT_REF_NAME/$STACK
deployment_tier: development
url: https://$REVIEW_URL
auto_stop_in: 1 week
on_stop: stop_review_app
script:
- echo "this is $CI_JOB_NAME job"
stop_review_app:
stage: deploy-review
when: manual
environment:
name: $CI_COMMIT_REF_NAME/$STACK
url: https://$REVIEW_URL
action: stop
script:
- echo "This job is supposed to stop the environements"
Running stop_review_app won't stop the environments that deploy:review jobs created because the environment name is dynamic and is based on the variables that were avaiable in the deploy:review job only.
Intended users
User experience goal
We should enable users to stop the environments created with the use of varibles in parallel:matrix in on_stop jobs.
Proposal
I guess that the MVC to enable this change would be to allow defining the same parallel:matrix variables in on_stop job as in the deploy job. Right now, the linter errors out if we do so:
This GitLab CI configuration is invalid: deploy:review: [app1] job: on_stop job stop_review_app is not defined.
stages:
- deploy-review
.parallel-matrix:
parallel:
matrix:
- STACK: [app1, app2, monitoring]
deploy:review:
stage: deploy-review
extends: .parallel-matrix
environment:
name: $CI_COMMIT_REF_NAME/$STACK
deployment_tier: development
url: https://$REVIEW_URL
auto_stop_in: 1 week
on_stop: stop_review_app
script:
- echo "this is $CI_JOB_NAME job"
stop_review_app:
stage: deploy-review
extends: .parallel-matrix
when: manual
environment:
name: $CI_COMMIT_REF_NAME/$STACK
url: https://$REVIEW_URL
action: stop
script:
- echo "This job is supposed to stop the environements"
It is possible that this is hapenning because of #239743 (closed)
Further details
-
From Customer ticket (internal):
We are deploying monorepos using a parallel matrix job:
deploy:review: stage: deploy review parallel: matrix: - STACK: - $CI_PROJECT_NAME FASTLY: "false" environment: name: $CI_COMMIT_REF_NAME/$STACK deployment_tier: development url: https://$REVIEW_URL auto_stop_in: 1 week on_stop: stop_review_appWe envisioned the above as part of a shared pipeline library, so our teams can just include the file that contains the above deploy job and it'll work for them with no other additions / changes. All they'd need to do is extend this job in their project's .gitlab-ci.yml and provide all of their stack names under parallel:matrix:STACK. The one
stop_review_appjob that we have defined is meant to clean up the environments, but we are unable to access the $STACK variable instop_review_app.
Permissions and Security
Following groups should have access to this new feature as they can edit the pipeline files:
- Developer (30) members
- Maintainer (40) members
- Owner (50) members
Documentation
- Document using
parallel:matrixwith on_stop jobs: https://docs.gitlab.com/ee/ci/environments/#working-with-environments
Availability & Testing
Available Tier
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.