Hi, Le 20/09/2022 à 17:35, Carsten Schoenert a écrit :
Hi, Am 20.09.22 um 16:13 schrieb Emanuele Rocca:Salsa CI is useful because it automatically performs binary/source builds, arm64 crossbuilds, and it runs various pretty important tests such as lintian, piuparts, reproducible build testing, and more. It also runs autopkgtest inLXC.quite most of these steps I usually need to do locally before I do any upload of packages. So I see no real gain to run any pipeline by default, for me this would be just burning energy in CPU cycles just for "because we can".CI/CD makes sense for me within a greater view such as is a version upgrade of package A not break other stuff in other packages, like does working all packages that now need to use a new version of pytest or setuptools, django etc. But that's not ready within the current way the default CI pipeline is working (in my POV).So no, for me it makes currently no sense to enable a CI thingy for ALL packages by default!
It all depends on your workflow indeed, and I assume nothing would prevent anyone from disabling CI on a per-repo basis (or, depending on the final consensus, enabling it on a per-repo basis as well).
Just to give some feedback on this, both the DebianOnMobile and Mobian team have CI enabled for all repos, along with 2 group runners for specific things (native arm64 builds and some non-packaging-related jobs needing kvm).
Over the past 2 years this has proven extremely useful for the following reasons: - it suits our workflow (develop locally, test it builds, then push and let CI handle the rest) - it doesn't require developers to manually run autopkgtest, lintian, piuparts or bhlc (which they could forget/not have the time to do), so all those tests are executed anyway, bringing immediate attention should any issue arise - we also have the benefit or reprotests which would be heavier to do locally - a significant portion of the team members have little experience with Debian packaging, so having all these checks automated allows them to focus on quality packaging rather than implementing a complete workflow including tests etc...
Opinions may differ of course, and both the aforementioned team are very small (both in terms of members and packages) compared to the Python team, but in our case we would definitely miss CI if it weren't there.
Cheers, Arnaud
We have automatic Lintian checks, the buildds itself, and also the autopkgtest infrastructure, why double such things, that's waste of energy and resources! The packages are not getting better by running tests multiple times within the same environment. And given my experience within other teams and groups, nobody really cares about packages that fail in some tests within a CI run. I strongly believe it wouldn't be better here.Sure you can do all this manually on your own, but it's better to live in a world where the machines work for us rather than the other way around. :-)I still don't see why this is a benefit.If you use an CI option within your own namespace is another thing, doing so make sense to me to prepare a new version for uploading.