Hi Simon, +1 on making debian/salsa-ci.yml (Salsa CI team recipe) the Go team default, and on Flight Deck preferring that file when present.
That matches what I hit: go-ci / test_the_archive was a SPOF; after switching the ncruces leafs (and new packages) to salsa-ci.yml, shared runners Just Work. Happy to help with doc wording or more migrations if useful. Removing the old CI-runner setup page (your MR !24) also makes sense to me. Thanks, Hermes Rodriguez <[email protected]> El lun, 14 sept 2026 a las 7:08, Simon Josefsson (<[email protected]>) escribió: > > Would it be possible to establish that as a new Go team policy? > > I reviewed our policy pages, and I could not find any references to CI > beyond a link on how to setup the CI runner, which I suggest to simply > not link to any more: > > https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/24 > > Another more active change could be to say something like > > Consider using normal Salsa CI setup through a debian/salsa-ci.yml file. > > Thoughts? > > I believe it would be nice if all debian-go packages would be modified > on Salsa to use debian/salsa-ci.yml, when that file exists for a > project, or the string > 'https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml' > when the debian/salsa-ci.yml file do not exist. > > /Simon > > Hermes Jesus Rodriguez Azuaje <[email protected]> writes: > > > Hi Otto, > > > > Thanks -- that matches what Simon said and what I hit in practice. > > > > I already upgraded to dh-make-golang 0.8.3-1~bpo13+1 on my packaging > > host, and the ncruces leaf packages on Salsa now use debian/salsa-ci.yml > > (standard recipe; gitlab-ci.yml is only a thin compat include). Salsa CI > > is green for those four. > > > > I will not pursue an extra go-ci runner. Happy to help with more > > salsa-ci.yml migrations if useful. > > > > Thanks, > > Hermes Rodriguez <[email protected]> > > > > El lun, 14 sept 2026 a las 4:53, Otto Kekäläinen (<[email protected]>) > > escribió: > >> > >> Hi, > >> > >> Please use dh-make-golang 0.8.3-1~bpo13+1 or 0.8.3-1 or newer when > >> creating packages, so you will get modern Salsa CI automatically and > >> do not need to put effort in legacy CI that does not have a runner, > >> nor seemed to work correctly when it did have a runner. > >> > >> In my experience when the `test_the_archive` it fails, it is always > >> for totally unrelated reasons. Furthermore, it also seems to pass even > >> if the Go package in question isn't building and is completely broken. > >> Hence to me it sees that this `test_the_archive` is useless, and > >> reviving it seems moot to me. It might have been useful in the past, > >> but it is no longer. I'd suggest all new packages use standard Salsa > >> CI. > >> > >> I think we should migrate all repos to use Salsa CI, so I have filed > >> now these as examples of what I think should be done: > >> > >> https://salsa.debian.org/go-team/packages/powerline-go/-/merge_requests/1 > >> https://salsa.debian.org/go-team/packages/golang-github-yuin-gopher-lua/-/merge_requests/4 > >> https://salsa.debian.org/go-team/packages/golang-gopkg-yaml.v3/-/merge_requests/5 > >> https://salsa.debian.org/go-team/packages/golang-github-alicebob-miniredis/-/merge_requests/4 > >> https://salsa.debian.org/go-team/packages/privatebin-cli/-/merge_requests/1 > >
