[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Golang team Salsa CI runner and documentation



sön 2024-11-24 klockan 21:03 +0800 skrev Shengjing Zhu:
> On Sun, Nov 24, 2024 at 8:56 PM Simon Josefsson <simon@josefsson.org>
> wrote:
> > 
> > Shengjing Zhu <zhsj@debian.org> writes:
> > 
> > > On Sun, Nov 24, 2024 at 8:31 PM Simon Josefsson
> > > <simon@josefsson.org> wrote:
> > > > 
> > > > Hi.
> > > > 
> > > > I never understood what
> > > > the 'test_the_archive' job does or what it helps with.  All
> > > > failures I
> > > > have ever encountered are cought by the standard Salsa pipeline
> > > > (and it
> > > > catches many other mistakes).  Does 'test_the_archive' test for
> > > > anything
> > > > that the normal Salsa pipeline would not catch?  I never
> > > > understood
> > > > that.
> > > 
> > > The normal salsa CI is for QA for the package itself.
> > > 'test_the_archive' is something like ratt, but designed with
> > > cache and
> > > efficiency (well, currently broken and half implemented). But
> > > they are
> > > two different things.
> > > 
> > > The normal salsa CI is good for "go programs", but I'm not
> > > convinced
> > > it's good for the large amount of "go libraries", which are just
> > > based
> > > on the standard template from dh-make-golang.
> > 
> > Then I think both jobs are useful.  The Salsa CI catches many usual
> > packaging mistakes for "go libraries" that "test_the_archive"
> > doesn't
> > (e.g., it performs real packages builds and runs lintian).  There
> > is no
> > conflict with running jobs from both pipelines.  There is added (of
> > course) CPU time to run all jobs, but presumably people donating
> > the
> > shared runners believe it is worth it for better Debian package
> > quality.
> > 
> 
> Please be aware that the large number of CI jobs not only consumes
> resources of gitlab runner, but also increases the load of the gitlab
> server. I'm already very sad with the slowness of our gitlab instance
> - salsa. Well you may argue that the number of go libraries is a
> small
> ratio of the whole debian packages, but I hope we can still save a
> little load for the salsa server.

One compromise would be to have an opt-in transition plan: only enable
Salsa shared pipeline for all packages that we upload from now going
forward.  Then the action plan is simpler:

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.

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.

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?

/Simon

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: