Skip to content
GitLab
Next
Closed
Issue created by Drew Blessing@dblessingDeveloper

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.ymls 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.

Edited by Jason Yavorska