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
) fromCi::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 asbuild
(Ci::Build
). It should bedeployable
, otherwise bridge jobs can't be exposed to UI. - Fix clone accessors of trigger job (
Ci::Bridge
) to cloneenvironment
keyword. (Otherwise, retried trigger job doesn't have environment metadata) - Fix
Ci::Pipeline#environments_in_self_and_project_descendants
fetching environments fromCi::Build
. It should includeCi::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 bothCi::Bridge
andCi::Build
. - Move
environment
config keyword fromlib/gitlab/ci/config/entry/job.rb
tolib/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
fromCi::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
- This approach is similar to Support Resource Group for cross-project and parent-child pipelines.