[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Add Salsa pipeline to default Go pipeline?



On Fri, Jan 19, 2024 at 11:18 PM Simon Josefsson <simon@josefsson.org> wrote:
>
> Hi.  I read about the Go teams CI/CD pipeline here:
>
> https://go-team.pages.debian.net/ci.html
>
> There is no mention of the "regular" Salsa pipeline:
>
> https://salsa.debian.org/salsa-ci-team/pipeline/
>
> I tried searching for earlier discussions but didn't find any.  The
> salsa pipeline includes many generic Debian packaging QA that the Go
> team CI/CD pipeline does not test as far as I can tell.
>
> What do you think about _adding_ the normal Salsa pipeline to the Go
> pipeline?
>
> Adding it should not conflict with the current "test_the_archive" job.
> It only means you would get some new jobs in your Salsa pipeline for Go
> packages, that are run on the normal shared Salsa runner.  The workflow
> rules may modify when jobs are run, but as far as I can tell, this would
> fix the current problem of running two jobs whenever you push a tagged
> commit, and similar issues.
>
> 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.

I would feel like a waste of compute resources to do generic QA on
most Go packages, as they are just simple packages from the same
template. Though some "program" packages are indeed complex and would
benefit from generic QA.

The old ci was designed to be resource saving. Though the one who
designed it has left Debian and this project is almost stalled.

> I see that shared runners are disabled for all Go packages, what was the
> reason behind that?  That needs to be enabled to use the normal shared
> salsa runners.  The "test_the_archive" job would still run on the go
> runner since the job is tagged, and that job would not run on the normal
> shared runners either.
>
> /Simon



-- 
Shengjing Zhu


Reply to: