On Fri, 26 Jul 2019 at 17:17:02 +0200, Bastian Blank wrote: > On Thu, Jul 25, 2019 at 02:31:55PM +0200, Daniel Leidert wrote: > > Therefor some time ago it had > > been requested to instead change the default at salsa.d.o system wide. > > Why do you think we would change it _if_ this option would exist?
This was requested in the past in https://salsa.debian.org/salsa/support/issues/26, and some people (including me) interpreted the reply as "no, but only because upstream doesn't have that feature". Was that interpretation wrong? The default of ./.gitlab.yml is problematic for Salsa *because* it's the upstream default, and git repositories on Salsa are most commonly used for Debian packaging where we try to minimize delta vs upstream source code: - Upstream projects developed on a Gitlab instance often include a ./.gitlab.yml that is designed to run on their infrastructure, not ours. If it works on our infrastructure, it's a waste of runner time: we want to test our packages, not the unmodified upstream source code. If it doesn't work on our infrastructure then it just gets in the way. - We can't remove ./.gitlab.yml from branches that match the upstream source code (e.g. upstream/* in DEP-14) because that would make those branches not match the upstream source code any more. - Anyone who wants to preserve the dgit-like property that the contents of git match the contents of the source package, and is using a patches-applied repository layout, can't remove ./.gitlab.yml without having a somewhat pointless commit in the source package that deletes it. - Anyone who wants to preserve the dgit-like property that the contents of git match the contents of the source package, and is using a patches-unapplied repository layout (e.g. gbp pq), can't remove ./.gitlab.yml at all. For those reasons I think something in debian/ would be a better default. The request in #26 was for debian/.gitlab-ci.yml. I personally think a non-hidden file (debian/salsa-ci.yml or debian/gitlab-ci.yml) would make more sense than a hidden file, but that's just bikeshedding really. Obviously the maintainers of individual packages can always configure their individual Gitlab projects, but that's an extra step to remember to take when creating a new package, the fact that it's per-project means there is no obvious value for what the different setting should be (reducing consistency between packages), and the fact that it's out-of-band Gitlab configuration conflicts with the general principle of keeping as much as possible in a VCS. smcv
