Hi. I'm also +1 on including all the jobs from the standard pipeline to Go project. I create a fork for each project I work on just to be able to run the normal Salsa pipeline, for QA purposes. I never understood what the 'test_the_archive' job does or what it helps with. All failures I have ever encountered are cought by the standard Salsa pipeline (and it catches many other mistakes). Does 'test_the_archive' test for anything that the normal Salsa pipeline would not catch? I never understood that.
I have a suggestion for alternative change. All Go Debian packages (to my knowledge) have a debian/gitlab-ci.yml with this content: # auto-generated, DO NOT MODIFY. # The authoritative copy of this file lives at: # https://salsa.debian.org/go-team/infra/pkg-go-tools/blob/master/config/gitlabciyml.go --- include: - https://salsa.debian.org/go-team/infra/pkg-go-tools/-/raw/master/pipeline/test-archive.yml I think we should stop this non-standard approach, to harmonize with the rest of Debian packaging. Here's my suggestion: 1) New Go projects on Salsa (dh-make-golang create-salsa-project) should set a defualt CI pipeline configuration as debian/salsa-ci.yml rather than debian/gitlab-ci.yml. 2) Change 'dh-make-golang make' to create a debian/salsa-ci.yml instead of debian/gitlab-ci.yml, and the new debian/salsa-ci.yml should look like this: # auto-generated, DO NOT MODIFY. # The authoritative copy of this file lives at: # https://salsa.debian.org/go-team/infra/pkg-go-tools/blob/master/config/gitlabciyml.go --- include: - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml - https://salsa.debian.org/go-team/infra/pkg-go-tools/-/raw/master/pipeline/go-jobs.yml Maybe we should pick a new authorative filename since we are introducing big changes. 3) Create the 'go-jobs.yml' file to run the 'test_the_archive' job in parallel with the standard Salsa pipeline. 4) Modify https://salsa.debian.org/go-team/infra/pkg-go-tools/-/raw/master/pipeline/test-archive.yml to include the default Salsa pipeline plus run 'test_the_archive' job, maybe via go-jobs.yml or inside current test-archive.yml. The purpose is to make all existing Go packages with debian/gitlab-ci.yml begin to use the standard Salsa pipeline, without any changes to the packaging. 5) Some configuration changes are needed to enable Shared Runners on all existing Go projects. Currently 'dh-make-golang create-salsa-project' disable the shared runners. Should we do a one-pass script to enable shared runners on all Go Salsa projects? Thoughts? /Simon Nilesh Patra <nil...@iki.fi> writes: > On 24/11/24 09:43, Otto Kekäläinen wrote: >> Hi! >> Are Go team members interested in being able to run plain Salsa CI >> on >> their packages? > > If I am not mistaken, by plain salsa CI you mean this thing > https://salsa.debian.org/salsa-ci-team/pipeline > right? > > I think so. This DC there was a discussion of getting rid of the legacy go > salsa CI since the > go world has moved from untagged repos to following good semver practices. > > Here are the notes for your ref: > https://salsa.debian.org/debconf-team/public/data/dc24/-/blob/main/etherpad/txt/152-go-team-bof.txt > > I personally use salsa CI pipeline (not the go one) for a couple of end user > apps that I maintain. > >> I have posted a Merge Request at >> https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/2 >> for discussion. >> Example of it being used: >> https://salsa.debian.org/otto/golang-github-tomasen-fcgi-client/-/pipelines/751593 >> ... >>>> On Tue, 17 Sept 2024 at 01:16, Otto Kekäläinen <o...@debian.org> wrote: >>>>> >>>>> Hi! >>>>> >>>>> I noticed the Go team has docs for having your own Salsa CI runner: >>>>> https://go-team.pages.debian.net/ci.html >>>>> >>>>> There are also Ansible scripts to deploy it at >>>>> https://salsa.debian.org/go-team/infra/provisioning/-/tree/master/ci-runner, >>>>> though the runner configuration is not fully identical to the docs. >>>>> >>>>> Perhaps this practice of having team-runners would make sense for >>>>> other teams as well? >>>>> >>>>> We recently added in Salsa CI the doc >>>>> https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/RUNNERS.md, >>>>> and I wanted to invite you to contribute to it in case you have best >>>>> practices to share or if somebody wants to refactor the Ansible script >>>>> you have and make it generic enough to be something we could recommend >>>>> for any team or DD to use across Debian, and potentially distributed >>>>> as a single file/directory from a centralized place. >>>>> >>>>> - Otto >> >
signature.asc
Description: PGP signature