Support CI job definition outside repository (external `.gitlab-ci.yml`)
Problem to Solve
The .gitlab-ci.yml
must currently exist inside of the project repository. It's possible to set a custom path within the repo, but that custom path can't point into other projects or arbitrary URLs. Customer wants a way to configure CI jobs other than the .gitlab-ci.yml
in the repo. There are some cases, such as when you're working in GitLab and contributing to a open source project that is external to GitLab it can cause problems because the .gitlab-ci.yml
can not go forward to the upstream (Zendesk: https://gitlab.zendesk.com/agent/tickets/19465).
It can also be used for numerous types of workflows where you have a variety of small code-bases that all need to be processed in the same way and either a) do not want the individual repos to be able to change the CI setup, and/or b) do not want to have to maintain in hundreds of repos. This is helpful for users coming from Jenkins who are using the https://github.com/jenkinsci/job-dsl-plugin plugin to solve the same use case, and makes migrating to GitLab easier.
Proposal
We will allow for configuring the path to the .gitlab-ci.yml
to an arbitrary URL:
- This would work for users that have a service that generates the config file dynamically
- This would work if the URL points to a file on a different repository (any GitLab instance), as long as the file is publicly accessible. Owners of the project hosting the config file should be able to restrict write access, providing a way to control access to the configuration in a scalable way.
- This would also let companies organize their
.gitlab-ci.yml
s in a central repository if that was desirable.
Alternative Approach
We also discussed limiting this to only repository paths, for example /path/to/.gitlab-ci.yml@another-group/another-project
. This has advantages that don't seem to be relevant for the moment, such as:
- pointing to a config file in a project that doesn't allow read by default
- knowing when the config file changes in order to trigger dependent pipelines
- knowing the version of the config file
We could expand on this in the future if it becomes relevant, but for now we can work on a simpler (and more flexible) scope.