On Wed, Nov 01, 2023 at 12:22:56PM +0900, Junio C Hamano wrote: > Victoria Dye <vdye@xxxxxxxxxx> writes: > > > As for adding the GitLab-specific stuff, I'm not opposed to having it in the > > main tree. For one, there doesn't seem to be a clean way to "move it into > > `contrib/`" - '.gitlab-ci.yml' must be at the root of the project [2], and > > moving the $GITLAB_CI conditions out of the 'ci/*.sh' files into dedicated > > scripts would likely result in a lot of duplicated code (which doesn't solve > > the maintenance burden issue this series intends to address). It is possible to change the location of the `.gitlab-ci.yml` in GitLab projects, so moving it into `contrib/` would work, too. But it does of course require additional setup by the project admin. > > More generally, there are lots of open source projects that include CI > > configurations across different forges, _especially_ those that are > > officially mirrored across a bunch of them. As long as there are > > contributors with a vested interest in keeping the GitLab CI definition > > stable (and your cover letter indicates that there are), and the GitLab > > stuff doesn't negatively impact any other CI configurations, I think it > > warrants the same treatment as e.g. GitHub CI. > > Thanks for expressing this so clearly. I do prefer to add this as > the first class citizen (more generally, I do not want to add new > things to contrib/ at this point) if we are going to use it. I certainly know that we in the Gitaly team will use this CI definition on a daily basis, which is my main motivation to add and maintain it in the future. I personally don't mind to add this as a first-class citizen, because for my own workflows I'll certainly treat it as such. And if others can benefit from it, too, then I'm even happier. I'll keep it in the default location at `.gitlab-ci.yml` then, thanks for your thoughts! Patrick
Attachment:
signature.asc
Description: PGP signature
