Disclaimer: If this feature is available, it has completely eluded me and, if that’s the case, my apologies in advance.
That said, we run multiple projects for our startup on gitlab and trigger various actions for build, testing, packaging (making docker images) and deployment in each of development, staging, and production. For this, I have used YAML anchors to abstract these actions and so I have a .performs_build: &performs_build task and a .performs_test: &performs_test hidden jobs, for example. Then dev:build: just includes the .performs_build, sets the appropriate variables, etc… specific for that environment and I can do the same for staging:build: and production:build:. It all works great. It’s nice an consistent.
When you have another project that should be basically the same, however, I’m forced to duplicate all those hidden jobs in the new project’s gitlab-ci.yaml file. About 75% of our gitlab-ci files are this common “boilerplate” code. Thus, if we change something about how we test, or more recently, deploy, we have to change EVERY .gitlab-ci.yaml file. It’s gotten to the point where I question whether they are all in sync and it becomes a pain to maintain. If you had multiple development projects using the same code, you’d most likely just refactor that section into a shared library that you can maintain in one place. That’s where I’m going here.
My thought would be to allow a common user or group YAML file that I can include all of that common “stuff” and then just reference it in the build. For example, if I could designate a gitlab project to hold the group’s common configuration, that would work and allow me the added benefit to use it for multiple teams (not all our teams have access to all the code even though they all build, test, package and deploy the same).
If anyone has alternate options or suggestions, I’d be happy to hear them too.
Thanks,
Dave