## Summary GitLab CI/CD has the feature [Multi-project pipelines](https://docs.gitlab.com/ee/ci/pipelines/multi_project_pipelines.html) i.e. `trigger` keyword. Currently, there is no capability to annotate the downstream pipeline as the deployment pipeline with `environment` keyword. See the epic https://gitlab.com/groups/gitlab-org/-/epics/8483+ 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 - [x] Testing thoroughly - Make sure that [the Environment/Deployment UI](https://docs.gitlab.com/ee/ci/environments/#view-environments-and-deployments) still works as expected. - Make sure that all of the `deployment.deployable` call in codebase still works as expected. - ... (Please add ) - [x] Documentation - [x] Feature flag addition/removal ### PoC Here is the [PoC MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124562) and the [demo video](https://youtu.be/xsyQTXkW8U8). You can see how the feature actually works from 5:23\~ in timeline. See https://gitlab.com/groups/gitlab-org/-/epics/8483#note_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](https://gitlab.com/groups/gitlab-org/-/epics/8483). ## Related issues - This approach is similar to [Support Resource Group for cross-project and parent-child pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/39057).