Otto Kekäläinen <o...@debian.org> writes: > Hi! > > I have now enabled via bulk-API call the shared instance runner for > all Go team packages.
Yay! Will new projects created by 'dh-make-golang create-salsa-project' get them enabled by default too, or does that require upgrading 'dh-make-golang'? /Simon > 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. >
signature.asc
Description: PGP signature
