On Tue Nov 5, 2024 at 10:45 PM CET, Diederik de Haas wrote: > > On Tue Nov 5, 2024 at 10:09 PM CET, Serafeim (Serafi) Zanikolas wrote: > > On Tue Nov 5, 2024 at 2:50 PM CET, Diederik de Haas wrote: > > [..] > > that's a great idea! technically, piuparts can run adequate but it's > > disabled in > > the piuparts job, so I'll give that a try first (we can always fall back to > > adding a dedicated adequate job if that causes any issues) > > I just took a quick look at the piuparts Salsa CI job definition, but I > didn't see anything related to adequate? > https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
piuparts by default runs adequate if installed (which is not the case in the piuparts job) but treats adequate errors as non-fatal: https://sources.debian.org/src/piuparts/1.4.4/piuparts.py/#L1649 https://sources.debian.org/src/piuparts/1.4.4/piuparts.py/#L3356 (piuparts in the context of the piuparts service does run adequate, so this is a well exercised code path, e.g. see https://piuparts.debian.org/trixie/) > But I'd prefer and recommend to make it a separate Salsa CI job and not > (try to) integrate it into another. > FWIW: not just wrt adequate, but with every (such) job I'm fine with adding a dedicated adequate job, if you feel strongly about this. meanwhile, fwiw, I've already prepared a MR to make piuparts fail on adequate errors: https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/558 I understand that the former would be cleaner, while the latter is slightly easier to implement. > > tangential sidenote: a package with defined autopkgtests gets baked in > > unstable > > for 2 days (rather than 5); it'd make sense to me that a package with > > configured > > and passing CI status should also get that favorable treatment, and a > > failing CI > > status should block migration to testing) > > I think CI in general is *very* beneficial, but I'm aware and understand > that not everyone is a fan of it or Salsa in general. > There's a lot more to it, but it's probably best to leave that out of > this discussion. ack, one battle at a time :)
signature.asc
Description: PGP signature
