Re: Golang team Salsa CI runner and documentation
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.
Reply to: