Aloïs Micard <creekorful@debian.org> writes: > The idea of the "old" CI was to trigger a massive rebuild of all go > packages each time a new version of given package is pushed. This > works very well in theory and allowed us to catch breaking changes > without having to rely on ratt. Building the whole "world" used to > took less than 30sec on a good machine with an up-to-date cache. This > is why this CI was so appreciated and useful. But does it even do that? I have prepared many packages that break other packages (and thus needs updates of build dependencies before upload) and I've never had the "old" CI fail in any useful way for me. To give an example of a package I'm working on now: I just pushed golang-filippo-bigmod 0.1.0 to go-team git. The 0.1.0 upload would break both opkssh and golang-github-openpubkey-openpubkey, which the "new" CI catches in a great way for me by rebuilding reverse dependencies: https://salsa.debian.org/jas/golang-filippo-bigmod/-/pipelines/865932 That means I need to add suitable Breaks and upload new versions of the build dependencies too, before doing the filippo-bigmod upload. However the "old" CI just signals green here: https://salsa.debian.org/go-team/packages/golang-filippo-bigmod/-/jobs/7587243 I have never had the Go CI fail in any way that helped me to improve anything, which I think is the primary use-case for a CI system. /Simon
Attachment:
signature.asc
Description: PGP signature