Enhance Multi-project pipelines to allow trigger tokens
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
It will be easiest to explain the problem after some background info & example.
Background
Assume we have two projects, and that these projects members do not overlap. One project is a "security" project and contains a CI pipeline which does security scanning, license and compliance checks. The other project is an "application" project.
The security project/pipeline will be centrally controlled and updated by our Security team. Having a central repository will allow the security team to make updates & enact changes without having to make any changes to the upstream application pipelines. It will also give the capability to audit and assess what applications are leveraging the security pipeline.
Workflow
- Application team runs through their normal workflow. The CI pipeline builds, tests and packages their application.
- The application team's pipeline triggers a pipeline on the security team project.
- The security pipeline runs, does any scans and checks, and reports the status back to the application pipeline.
Problem
The problem lies with the feedback mechanism for the Security pipeline to report back status on the application pipeline.
We have tried two approaches:
- Multi-Project pipelines - With this approach it was acceptable from a UI perspective but because the application team does not have access to the security team's project, the pipeline was not able to be triggered. Therefore, multi-project pipelines are not an option.
- API Triggers - With this approach we were able to trigger the pipeline successfully via a "trigger token" created on the security pipeline. What this approach is missing is a good feedback mechanism to report the status of the build to the application pipeline.
Intended users
Security, Compliance, Team leads and Project managers.
Proposal
Enhance the "multi-project pipeline" to allow the specification of a trigger token. I believe this will improve the reporting and feedback of an external pipeline which is initiated via trigger token.
Proposed .gitlab-ci.yml:
rspec:
stage: test
script: bundle exec rspec
staging:
stage: deploy
trigger:
project: my/deployment
branch: stable-11-2
token: $TRIGGER_TOKEN
In this example, $TRIGGER_TOKEN would have been entered as a CI/CD variable on the project.