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. Btw, I am looking at the go-kit-kit package and the etcd package with a goal of a experimental upload if I get reverse builds to behave. I've noticed that old etcd causes build failures for new versions of several packages. /Simon
Attachment:
signature.asc
Description: PGP signature