More ways to specify CI build configs and trigger builds
Description
I am using Gitlab CI to automate builds and deployments as part of a larger PaaS system. All the Gitlab interaction is done via the API. What I want is for users to be able to Git push to a repository and have the build started automatically. Specifically I want the administrator of the system to control the build configuration and users should not be able to view/edit the config, nor should they really need that knowledge. They just push their code and the build is automatically started and ends up with a Docker image in the Container Registry.
The problem is that Gitlab CI relies on the .gitlab-ci.yml
file to be present in the repository. I appreciate the idea of having the build config itself under version control, but it makes the above scenario difficult because any user with access to the repo could potentially view/edit the build config.
What I would like to see is some way for "push to build" to work without the .gitlab-ci.yml
file being visible in the repository, or maybe not even required at all (see below suggestions).
Proposal
As I see it there are a couple of approaches to this:
-
Add option to make
.gitlab-ci.yml
hidden from repo for particular user groups. Not sure if this is possible technically as a git pull or file browse through the UI would probably always show the file? -
Add new endpoint to the Builds API to trigger builds on-demand by specifying a
.gitlab-ci.yml
file as part of the request. The syntax could be the same, just that the config is parsed by the API instead of read from a file on disk. It would then be possible to invoke the build in a push event trigger. With this solution the.gitlab-ci.yml
file is not needed in the repo at all. -
Add ability to store the
.gitlab-ci.yml
out of repo. Administrators can add a config per branch through a new section in the web UI or through the API. This approach requires Gitlab to store the configs for each repo in some way (database or file outside of Git repo) so more state is required and the implementation would probably also be the most involved.
Probably both options 2) and 3) would be useful, but personally I would be able to support my use case with just option 2).
What do you guys think?
Links / references
There are multiple related issues, such as gitlab-ce#15041 and gitlab-ce#15561.
~"feature proposal"