Or at least, cross-repo inheritance.
I've worked at a couple of places now where GitLab CI templates are heavily used, included across repos, and inherited from.
I've found it confusing, inflexible, and an enemy of build reproducibility.
In a repo where this is done heavily, if I want to change something, I must figure out:
- Does my
.gitlab-ci.ymlactually contain this job at all? Or is it from a template somewhere else? - Where the heck is it (or its parent) coming from? This repo includes templates from three other repos, and they include templates from other repos too. Where it at???
- How do I change the parent job without breaking any other pipelines that depend on it? Maybe I can just inherit from it and add a
before_script? But what if the parent job gets updated with its ownbefore_scriptlater, and my overriding it breaks something? - Will the person who owns the parent template's repo let me change it?
So after getting all of that out of the way, I make the change in the template repo. It breaks someone else's pipeline somewhere. But there wasn't even a commit to their repo. Their pipeline just suddenly just starts failing. What?? This totally breaks build reproducibility!
I've gotten to where I'd rather just have a bunch of duplicated GitLab CI code across repos.
Am I crazy, am I missing something, or do others feel the same?
Top comments (7)
Since version 13.9, there is
!reference tags:docs.gitlab.com/ee/ci/yaml/yaml_op...
Use the !reference custom YAML tag to select keyword configuration from other job sections and reuse it in the current section. Unlike YAML anchors, you can use !reference tags to reuse configuration from included configuration files as well.
It looks like that link has been now dead after 2021-11. New URL would be
docs.gitlab.com/ee/ci/yaml/yaml_op...
I agree, GitLab CI is lacking something like tags for inherited steps/jobs, something like
[from-parent:user/repo]maybe (even though that's not YAML, that's the idea)Like this? docs.gitlab.com/ee/ci/yaml/yaml_op...
Exactly like this! I had no idea this existed, thanks!
I totally agree. I prefer the way used bu DroneCI where every task are small dedicated script contain inside docker image.
This let you compose instead of inherite and you can target a specific image version for your job. So if someone update the master image, your build is not broken.
While being one of the largest developer of GitLab in the world, totally I agree 😭