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

Re: Changing gitlab-ci.yml for user-facing programs?



On Fri, Jul 15, 2022 at 04:22:52PM +0530, Nilesh Patra wrote:
> Hi,

Hey,

> 
> The current salsa-CI setting is designed in a way that it checks
> that onupdating a package a reverse dep is not breaking (as things work this way in the
> go world) -- great.
> 
> However, it still lacks the intensive testing that usual
> salsa_CI config has (build + i386build + lintian + reprotest + arch:any build + arch:all .. so on)
> due to understandeable reasons for now (not much resources IIRC?)
> 
> However I think the current config is not useful for packages that users will directly
> use as programs, and which do not have an arch:all lib package.
> For example: aerc, micro, riseup-vpn, go-sendxmpp et. al. and I would much rather like to use
> the default salsa-ci config pipeline for these and I have changed it for a couple of them already.
> 
> What do you think? And is there an objection in general?

I don't see why the Go Team packages should not run _also_ the whole
Salsa CI pipeline.

Maybe some tests are not that relevant, don't know which and why, but
I would be happy to see with my eyes what's going on instead of just
assuming things. Pipelines are exceptionally good at breaking at the
unexpected place.

I made a naive experiment a couple of days ago [0] and included both the
pipelines. It did not work, I evidently have quite some homework to do.

Now, how to keep an overview of which pipelines are running where?

Dom

[0] https://salsa.debian.org/cavok/golang-github-iovisor-gobpf/-/pipelines/399438

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05

Attachment: signature.asc
Description: PGP signature


Reply to: