Hi, Thanks Sylvain and Emilio for providing insight into the history of the (E)LTS CI pipelines/workflow, explaining that current state is mostly a consequence of historic state and not the ideal end goal, and for expressing agreement on key points how to update/streamline it.
It would be nice though to hear more people chime in now, so that if I go ahead and implement some improvements, it is likely to be useful and not be blocked later and turn out to be wasted effort. On Fri, 29 Nov 2024 at 09:46, Otto Kekäläinen <o...@debian.org> wrote: > > Hi! > > > As the initial author of the fork, I contributed some improvements that I > > thought would be accepted upstream. However, I didn't think other changes > > (such > > as hacks to support jessie) would be accepted, as some of those hacks had > > been > > removed previously. If the salsa-ci maintainers agree to include some of > > those > > changes, I'd be happy to clean them up and submit them. But we'll still > > need the > > fork unless the salsa-ci project starts to build images for jessie ELTS > > including freexian repositories, which I'm not sure is going to happen. > > I think it is better we all contribute to one pipeline as there is > only a handful of us volunteers around, at least currently. Thus, > personally as Salsa CI contributor, I am OK if we now going forward > keep in Salsa CI postpone dropping support for releases that are > currently there, i.e. keep Bullseye until 2031-06-30. Resurrecting old > releases is probably too hard. > > Also with my MariaDB packager hat on, it is much easier to do > security/maintenance updates quickly for 3-8 different Debian and > Ubuntu releases if there is a minimal amount of process/infrastructure > changes required per release. > > > However, for LTS, we have made changes recently to use the salsa-ci bullseye > > images, dropping them from our fork. The recipes et al can still be used > > from > > the lts-team/pipeline project though. > > We did? Maybe that is easy to still resurrect if it wasn't long time > ago. Bullseye isn't even ELTS but just LTS now, and I just did two > months ago > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/18 > and all testing was running on Salsa CI as base + per-package > customizations. > > > > 5. Are you aware that the RELEASE does not need to be set manually at > > > all? You can just keep the existing debian/salsa-ci.yml in the package > > > and once you add a new changelog entry for stretch/buster/bullseye all > > > the jobs in the CI pipeline will automatically build and test using > > > the release in debian/changelog (only exception being Lintian, which > > > currently always runs the Sid version)? > > > > I wasn't aware of that when I did the pipeline fork, that's the reason I > > added > > release-specific recipes. That magic isn't going to work when a changelog > > entry > > contains UNRELEASED though, which is very common. I recently saw some > > changelog > > that had bookworm-security-UNRELEASED or similar, and I didn't think it was > > for > > this reason. However if one uses UNRELEASED, and sid is assumed and the > > pipeline > > breaks in unexpected ways (or worse, passes when it should fail) then > > that's a > > bad assumption, and wouldn't have happened by explicitly setting the > > release in > > the CI config file, or by using a release-specific recipe. Just like we set > > "branch-name = bullseye" in gbp.conf, instead of relying on guessing the > > release > > from d/changelog. > > You are right, when the first upload to a non-unstable is done and the > most recent entry has UNRELEASED and all entries before it has > 'unstable', there is no way for the autodetection to know that > UNRELEASED actually means something else. Using > 'bookworm-security-UNRELEASED' seems like a good way to solve it. > > > To me, the only reason to rely on that automagic is if we drop salsa-ci.yml > > entirely and use a script to set the CI conf file to > > `recipes/debian.yml@salsa-ci-team/pipeline' or similar. But then, since > > there's > > no config file in the repository, one cannot tweak things to e.g. ignore one > > lintian tag, or disable the blhc job, or whatever, so again I don't see the > > benefit. > > I would recommend to have the salsa-ci.yml file in the package > explicitly. It is much easier to customize it and fix stuff if the CI > pipeline is broken. If the CI pipeline is defined centrally, it is > both invisible to contributors and forks, and it is impossible to fix > if CI is failng due to CI issue, and then the package will be stuck > with failing CI and the whole point with CI becomes moot. Also the CI > config `recipes/debian.yml@salsa-ci-team/pipeline` would apply to all > branches, and for example run on all pristine-tar branch pushes. It is > much better to just have a CI file on each branch that controls > exactly what that branch in that package does for CI.
