Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab
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
Reply to: