Shengjing Zhu <zhsj@debian.org> writes: > 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. Agreed! I think a third CI would be useful for Go: having a periodic rebuild of all Go packages, including tests, to make sure they are still working when other packages are updated. Right now it seems we don't catch these issues until someone outside of the Go team do a archive-wide rebuild. > 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. Definitely -- however I don't see how we can ever have confidence in uploads of core Go packages without building all reverse dependencies. If that building is on developer local laptops or via Salsa is not that different from a resources perspective. The CPU usage needs to happen somewhere. Going via Salsa allows everyone to easily see the result and help resolve each issue, and to have higher confidence that we don't miss anything since it is automated. For package failure rebuilt via 'ratt' only the developer see the results. Of course, reverse dependency builds on Salsa should only be done manually for critical packages and not automatically on every push. /Simon
Attachment:
signature.asc
Description: PGP signature