pipeline process isolation from code repo
Problem to solve
Separation between control over project code and pipeline code, especially for open source projects, so that you can share and get changes from forked/branched code into master (project code) without risk to pipeline.
Intended users
Further details
Proposal
Take .gitlab-ci.yml pipeline definition file and put under a seperate pipeline repo under group level.
- Group-MyTestProjects
repo-pipeline
- > repo-Project-1.gitlab-ci.yml
- > repo-Project-2.gitlab-ci.yml
repo-Project-1
- > src
- main.java
- > lib
- util.jar
- pom
repo-Project-2
- > src
- main.java
- > lib
- util.jar
- pom
Permissions and Security
Any dev/ops persom responsible for managing pipeline for all the project under that group will have access to the repo-pipeline, and can make changes in the repo. Merge request will be validated against the pipeline file changes and the build of corresponding project master branch assuming master is a good good.
Any dev/ops persom responsible for managing code for a project under that group will have access to the repo-Project-X repo and can make changes in the project repo without worrying about making changes to pipeline and impact the pipeline. Merge request will be validated against with the pipeline definition file in the master for the project in rep-pipeline.
Any impact to either project code or pipeline can be seperately validated with respective project/pipeline master branches at merge request level.
What does success look like, and how can we measure that?
No risk of pipeline impact with any changes in project code, and vice versa.