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