Hi Simon, Thanks for the reply.
Honest answer: I do not have a strong attachment to test_the_archive itself. What bit me was operational: after Flight Deck import, every push showed a red/stuck pipeline (tag go-ci, no runner, no job trace). As a new uploader without project Settings, that looked like "CI is broken / I did something wrong", and the docs still present go-ci + test_the_archive as the default path via debian/gitlab-ci.yml. For catching packaging mistakes I rely more on local debuild/lintian and (when it runs) Salsa CI. If the team consensus is that test_the_archive is low value and the future is debian/salsa-ci.yml + shared runners, I am happy to follow that and not spend effort on another go-ci box. The runner offer still stands if someone wants spare go-ci capacity; otherwise I will treat weekend go-ci outages as non-blocking and focus on Salsa CI / local smoke. Thanks, Hermes Rodriguez <[email protected]> El lun, 14 sept 2026 a las 3:59, Simon Josefsson (<[email protected]>) escribió: > > Hermes Jesus Rodriguez Azuaje <[email protected]> writes: > > > Hi, > > > > I have been packaging the ncruces / pgwd chain under go-team/packages. > > Over the weekend several test_the_archive jobs stayed stuck / failed with > > no matching runners for tag go-ci (no job trace). That matches a single > > point of failure on the current go-ci pool. > > What value do you find in the test_the_archive CI job? I'm not > objecting to fixing it, but I never found it useful for any of my > workflows. When does it help you notice a problem in the packaging? > For me it normally just always succeeds regardless of package mistakes, > and sometimes it consistently fail (e.g., for packages with repacked > upstream sources) even though there is no problem with the package. > > /Simon
