Annotate non-deployment jobs with `prepare` keyword on `environment:action:` keyword
Problem to solve
The current .gitlab-ci.yml environment:action keyword does not accurately represent cases where an environment is not resulting in a deploy job. We are looking to more clearly annotate in the yaml and environment experience the state of non-deployment environment jobs
Today, we have environment:action:
keyword in .gitlab-ci.yml that supports start
and stop
as the value. If it's not specified, start
is used by default. But this behavior causes some problems in advanced CD scenario.
Problem 1: Approvals for deployments
Looking at this blog post https://about.gitlab.com/blog/2020/02/20/protecting-manual-jobs/, it suggests defining two jobs approve
and deploy
with the same environment:name:
. The approval
job must specify environment:
keyword because it restricts manual-job permission via protected environments. For example, user has the following .gitlab-ci.yml:
approve:
stage: approve
script: echo
environment:
name: production
url: https://example.com
when: manual
allow_failure: false
deploy:
stage: deploy
script: echo
environment:
name: production
url: https://example.com
This works as-is, however, it causes a side effect that users see approve
job as the latest deployment job in environment/deployment page, which is not true. This is because the system recognizes the appprove
job as environment:action:start
job, which implies that the job is supposed to start an environment with deploying new code, which again not true.
Problem 2: Preparation for deployments
As @caroga pointed out in #215469 (comment 331095252), environment:
keyword could be specified to a job that just builds an docker image for a latter deployment stage. In this case, environment:
must be specified because environment-specific variables are used in the build script. For example, user has the following .gitlab-ci.yml:
build-review-nginx:
script: build_nginx
environment:
name: review
build-review-fpm:
script: build_fpm
environment:
name: review
However, it doesn't work as intended because Limit the pipeline job concurrency and Skip outdated deployment jobs features do NOT allow to run multiple jobs to run on the same environment concurrently. This is because the system recognizes the build-review-nginx
and build-review-fpm
jobs as environment:action:start
job, which implies that the jobs are supposed to start an environment with deploying new code.
Ideally, since these jobs are just for prepartion, it should not be affected by the above features. In other words, these jobs should run concurrently.
Proposal
Expand keywords to environment:action
to correctly indicate what each job is meant for and annotate jobs that are not resulting in a deployment.
environment:action: |
Description | Usage Example |
---|---|---|
prepare |
The pipeline job is to prepare for a latter deployment stage | Build a docker image for a k8s cluster used as a production environment |
start |
The pipeline job creates/updates an environment. | Updating a production environment by deploying the code |
stop |
The pipeline job stops an environment. | Terminates a review app by destroying VM |
Important Note.
- Jobs with
action:prepare
shouldn't be affected by Concurrency Limit or Skip outdated deployment jobs, since it doesn't modify an environment at all. - If
environment:action:
is not specified,action:start
is selected by default.
Example
approve:
stage: approve
script: echo
environment:
name: production
url: https://example.com
action: prepare # Annotation that this is not a deployment job
when: manual
allow_failure: false
build-review-nginx:
script: build_nginx
environment:
name: review
action: prepare # Annotation that this is not a deployment job
build-review-fpm:
script: build_fpm
environment:
name: review
action: prepare # Annotation that this is not a deployment job