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.
