Define a process to vendor files in releases
Some files are vendored in
gitlab-ee, and are shipped as part of the product. For example,
gitlab-ci.yml files and project templates are part of this story.
At the moment, there is no clear process on how these files are vendored during the release, and this is creating a lot of problems and unneeded confusion. So we can absolutely improve how it works!
This is happening mainly for Auto DevOps template (https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml) that is used also as the implicit pipeline definition if no file is defined. We change it a lot, and every time it should be vendored again into the
gitlab-ce repo. The ~"Pick into 10.4" label didn't work well because the file is on a different repo.
As far as I know, the process now is:
- changes are merged into the
- a MR should be manually created using a
raketask, to vendor the file into the
- this MR should be merged into the stable branch (or the release branch) to be part of the product
This has a few weaknesses:
masterbranch of the
gitlab-ci-ymlrepo can be "dirty" after the feature freeze, so managing features for the next release and fixes for the current one is difficult (we probably need the equivalent of the stable release branch here)
- the vendoring process is not automatically done, but someone should run a manual task (this is prone to errors, we should automate)
- stakeholders are the developer of the feature and the release managers, but it is not clear who is in charge for what (it should be part of checklists I suppose)
It is probably difficult to have a zero-pain process, but for sure we can make it better!