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? 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. 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. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Attachment:
signature.asc
Description: PGP signature