Hi! I have now enabled via bulk-API call the shared instance runner for all Go team packages.
This means that anyone can now use Salsa CI in Go packages (in addition to the current CI that was running Go team specific runner). Nothing is actually running Salsa CI immediately. This was just done to unblock anyone from trying to run Salsa CI. Example of a package already using Salsa CI: https://salsa.debian.org/go-team/packages/glow/-/pipelines/787862 Implemented via: https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/4 On Sun, 24 Nov 2024 at 17:22, Otto Kekäläinen <o...@debian.org> wrote: > > Hi all! > > Thanks for multiple replies on the topic after a couple weeks of > silence. I am already in progress doing the things suggested here, and > now with the additional feedback I think I can finalize everything > today in > https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/2 > and start using it on my Go packages initially, and if no regressions > surface perhaps proceed with the team-wide change in a couple of > weeks. > > > 1) Patch dh-make-golang to create debian/salsa-ci.yml instead of > > debian/gitlab-ci.yml, pointing to a combination of salsa CI and > > test_the_world. And drop the disabling of shared runners on salsa on > > create-salsa-project. > > Let's merge > https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/2 > first to update file contents, and I can follow up with file rename. > > > 2) On every package update, maintainers do the pipeline change > > manually. > > > > OTOH, this costs maintainer time compared to my other plan which just > > costs shared runner time. So I think this is a worse trade-off, human > > time is costlier than CPU time. > > This is now what > https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/2 > does and by necessity as instance runners are not (yet) enabled in > go-team. > > > My perception is that while definitely salsa speed could be improved, > > it is not that much of a difference compared to working on gitlab.com > > which I do a lot as well, and find acceptable. > > > > Maybe this is a question for the Salsa CI team, are they okay with > > shared runner CPU time for Go packages? > > The Salsa CI team only maintains the CI code. We have no access or > visibility into the state of Salsa itself, nor the shared runners. We > for example do not know what is the capacity or utilization-% of the > shared runners. We do however know that there are several hardware > donors pending the Salsa Admins to accept donations > (https://salsa.debian.org/salsa/support/-/issues/301) so I suspect the > bottle neck here is not CPU time, but human time to maintain Salsa, > and human time to maintain packages divided among doing new package > versions vs fixing regressions that went into the archive. Salsa CI > hopefully can save human time on the latter one, and DEP18 may help > drive a culture of more team work and code reviews to improve aspects > in ways that CI doesn't.
