On Sat, Jul 16, 2022 at 08:24:20AM +0530, Nilesh Patra wrote: > On Fri, Jul 15, 2022 at 10:39:24PM +0200, Domenico Andreoli wrote: > > > 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. > > The reason was resources IIRC (as written above) but I could be mistaken. Do you mean that the added usage due to the Go Team executions could overload the Salsa CI infra? If that is the case, it's better to escalate and seek for adding resources. The Project has quite some savings. > > Maybe some tests are not that relevant, don't know which and why, > > Reprotest, blhc and cross-build are the non-relevant ones as far as I can see. > All three need to be fixed at compiler level. Does the compiler still need to be fixed? If yes, then would be nice to exclude just the non-meaningful jobs instead. > > but > > I would be happy to see with my eyes what's going on instead of just > > assuming things. > > I share your opinion here. > > > Pipelines are exceptionally good at breaking at the > > unexpected place. > > Indeed! > > > 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. > > You need to modify the pipeline .yml files and check :) I will. My objectives: - run the regular Salsa CI pipelines on the regular Salsa runner - run the Go Team pipeline on the Go Team runner - selectively disable the non meaningful Salsa CI jobs by using flags, leaving the Salsa CI configuration otherwise untouched - possibly in a centralized team place instead of a per-project base > > Now, how to keep an overview of which pipelines are running where? > > You can't I guess, but is that even relevant though? - Just trying to understand. > One point is that using different configs adds inconsistency across team-packages. It's exactly my point, it's important to keep the inconsistencies well under control. Dom -- 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