Path: csiph.com!1.us.feeder.erje.net!3.us.feeder.erje.net!3.eu.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!news.uzoreto.com!aioe.org!bofh.it!news.nic.it!robomod From: Arnaud Ferraris Newsgroups: linux.debian.maint.python Subject: Re: Enabling salsa-ci on all Debian Python Team repos Date: Wed, 21 Sep 2022 13:20:01 +0200 Message-ID: References: X-Original-To: debian-python@lists.debian.org X-Mailbox-Line: From debian-python-request@lists.debian.org Wed Sep 21 11:12:32 2022 Old-Return-Path: X-Amavis-Spam-Status: No, score=-109.085 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LDO_WHITELIST=-5, NICE_REPLY_A=-1.175, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=0.001, USER_IN_DKIM_WELCOMELIST=-0.01, USER_IN_DKIM_WHITELIST=-100] autolearn=ham autolearn_force=no MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Debian-User: aferraris X-Mailing-List: archive/latest/20328 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/155ab1a7-88d4-16c6-6502-c2bd7f45d78f@debian.org Approved: robomod@news.nic.it Lines: 77 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Wed, 21 Sep 2022 13:11:55 +0200 X-Original-Message-ID: <155ab1a7-88d4-16c6-6502-c2bd7f45d78f@debian.org> X-Original-References: <6f483545-27cb-0d05-d813-50c482284e6c@t-online.de> Xref: csiph.com linux.debian.maint.python:14486 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 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! 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. >