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 in
LXC.
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!
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.
--
Regards
Carsten
