On Tue, Jan 19, 2021 at 12:27:31PM +0100, Raphael Hertzog wrote: > Hi, > > On Mon, 18 Jan 2021, Antonio Terceiro wrote: > > FWIW, The ci.debian.net infrastructure is mostly independent from > > autopkgtest, so we could have different types of jobs there. This could > > be used for lintian, but also for on-demand rebuilds, and other types of > > checks that needs to be done to packages in the archive. the debci > > codebase has seen a lot of work to properly handle stuff like this in > > the last 6 years, and it would be a win if we can reuse that for other > > use cases, instead of someone having to start from scratch having to > > learn again everything that I did in the last 6 years working on ci.d.n. > > Can you expand on the kind of features that ci.debian.net offers and what > kind of mistakes we would likely avoid by reusing it? To name a few: - distributed processing - data retention policies - web interface - monitoring > From my (relatively remote) point of view, ci.debian.net seems really > very basic in terms of features related to scheduling of jobs. > > From my own usage in Kali (autopkgtest.kali.org), I noticed you can't > even request to test a specific version of a package... you get whatever > version is available in the specific mirror that you are using for your > test, even if it's not (yet) in sync with the one used by the code that > requested that job. autopkgtest does not support that, so debci doesn't offer it as well. > There's also no possibility to have differentiated workers (qemu vs > lxc-based) and have the jobs dispatched to appropriate workers. > > Scheduling features might not be important for lintian processing but I > believe it's a must have if we want to consolidate more jobs in a single > place. I didn't say it was ready for it now, but that it could be done. My hope is that this, and other use cases, could be enabled by collaborating on existing infrastructure, instead of creating yet another one.
Attachment:
signature.asc
Description: PGP signature