GitLab Next

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