Skip to content

Support `environment` keyword with `trigger` keyword (Parent-child/Multi-project pipelines)

Summary

GitLab CI/CD has the feature Multi-project pipelines i.e. trigger keyword. Currently, there is no capability to annotate the downstream pipeline as the deployment pipeline with environment keyword.

See the epic Support `environment` keyword with `trigger` ke... (&8483 - closed) for more information.

User experience goals

Example:

deploy:
    trigger:
        project: some/other/repo
        branch: master
    environment:
        name: dev
        url: https://app.dev.blah.com

Proposal

The key idea is to allow trigger jobs (Ci::Bridge) to be associated with deployments/environments. Currently, only normal jobs (Ci::Build) can be assocaited with it. To do so, we need to do some refactoring and move the deployments/environments logic to the superclass (Ci::Processable)

Technical details

  • Move the deployments/environments logic to the superclass (Ci::Processable) from Ci::Build.
  • Remove the deployments/environments logic (no-op) from the Ci::Bridge.
  • Environment-stop feature redirects user to a pipeline page instead of a job page. Because we don't have trigger job page yet (it will result in 404)
  • Fix app/graphql/types/deployment_type.rb referencing deployable as build (Ci::Build). It should be deployable, otherwise bridge jobs can't be exposed to UI.
  • Fix clone accessors of trigger job (Ci::Bridge) to clone environment keyword. (Otherwise, retried trigger job doesn't have environment metadata)
  • Fix Ci::Pipeline#environments_in_self_and_project_descendants fetching environments from Ci::Build. It should include Ci::Bridge as well (otherwise users can't see environments in MRs)
  • Replacing all "Build" occurencies by "Job" in Environment/Deployment models/services/workers. This is for consistency that the entities can have both Ci::Bridge and Ci::Build.
  • Move environment config keyword from lib/gitlab/ci/config/entry/job.rb to lib/gitlab/ci/config/entry/processable.rb. This allows users to specify the keyword in .gitlab-ci.yml.
  • Move the environment variables to lib/gitlab/ci/variables/builder.rb from Ci::Build#variables. This allows upstream pipelines to pass environment context to the downstream jobs.

Other TODOs

  • Testing thoroughly
    • Make sure that the Environment/Deployment UI still works as expected.
    • Make sure that all of the deployment.deployable call in codebase still works as expected.
    • ... (Please add )
  • Documentation
  • Feature flag addition/removal

PoC

Here is the PoC MR and the demo video. You can see how the feature actually works from 5:23~ in timeline.

See &8483 (comment 1450917482) for more information

Testing and Follow-ups

We should test well from not only .gitlab-ci.yml perspective, but also UI/API perspective. The deployments/environments features are quite broad and we might see unexpected behaviors on edge cases.

If we found a follow-up issue, please create and link it to the parent epic.

Related issues

Edited by Shinya Maeda