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

Re: Add Salsa pipeline to default Go pipeline?



On Wed, Jan 24, 2024 at 4:07 PM Simon Josefsson <simon@josefsson.org> wrote:
>
> Shengjing Zhu <zhsj@debian.org> writes:
>
> >> >> How do you all QA test Go packages before uploading them without a Salsa
> >> >> pipeline?  Manually on local developer machine?
> >> >>
> >> >
> >> > Yes, I need to sign the changes locally, so I build packages locally.
> >>
> >> Right, I build locally too before signing uploads.  I was thinking about
> >> the QA process.  Given the number of uploads of newer versions of a go
> >> package that are later reverted due to reverse dependency build issues,
> >> I think some additional pre-upload QA aspect for go packages to catch
> >> these issues would be good.
> >>
> >
> > The test_the_archive was designed to catch these reverse dependency
> > build issues. Since every commit needs to rebuild many packages, it
> > needs to be efficient. test_the_archive uses the go compiler's cache.
> > However it currently only covers the build phase, not test phase.
> > Unfortunately no further development has happened.
>
> Yeah, I think the test phase and other tests are useful.
>
> Compare successful pipeline for golang-github-go-kit-kit built today:
>
> https://salsa.debian.org/go-team/packages/golang-github-go-kit-kit/-/jobs/5197263
>
> With this FTBFS bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061032
>
> A Salsa CI pipeline for the same package indicate test problems:
>
> https://salsa.debian.org/jas/golang-github-go-kit-kit/-/pipelines/629760
>
> So I think we should start to test Go packages using the standard Salsa
> pipeline too, to catch issues like this.  I'm not saying we should
> remove "test_the_archive", just agument it.

There are two types of CI here.

The go-kit example you mentioned here is for testing the package
itself. When go-kit was uploaded, its test was successful. However it
got broken some day. I don't think the salsa CI you mentioned here can
catch that. The reason I said this might not be useful for most Go
packages, is because most Go packages are libraries and share the same
template. But it's useful for complex Go program packages. Meanwhich
for these Go program packages which don't have -dev library package,
the reverse deps test is not useful for them.

The other CI is for testing the reverse deps, like "test_the_archive",
and your previous example for grpc-go,
https://salsa.debian.org/jas/golang-google-grpc/-/pipelines/629139
The #629139 pipeline takes 42 minutes, which is not a healthy system
and needs to be used individually and carefully.

--
Shengjing Zhu


Reply to: