Simon McVittie wrote: > Relatedly, I would like to be able to capture some information about > builds even if (perhaps especially if) the build fails.
That is a good point that I hadn't considered. > so that failing builds can also produce artifacts, to help the > maintainer and/or porters to figure out why the build failed. Agreed that this is useful. > handling build logs is not dak's job (and I don't think handling > things like the binutils test results should be dak's job either). It has always felt weird to me that build logs are entirely separate to the archive off in a side service rather than first-class artefacts that people occasionally need to look at. Also that the maintainer build logs don't end up anywhere and are probably just deleted. I think the same applies to the buildinfo files and also these tests results and other artefacts that are mentioned in this thread. > Here's a straw-man spec, which I have already prototyped in > <https://salsa.debian.org/debian/sbuild/-/merge_requests/14>: This seems better than my proposal, modulo the above and also the repro builds need for a way to distribute buildinfo files somehow. IIRC last time the build artefact discussion came up I was cycling between having the artefact handling in the sbuild configs on the buildds for quick implementation vs having it in debian/ dirs for distributed maintenance by maintainers. I think there is a fundamental question here that needs answering definitively: who is the audience for the artefact feature? * Is it individual package maintainers who want test result details? * Is it build tool maintainers who want data on tool use/failures? * Is it porters who want more detailed logs in case of failure? * Is it buildd maintainers for some reason? * Is it RC bug fixers? * Is it all of the above? Once that is answered, then we can think about how to accommodate how and where the list(s?) of files are to be maintained? * in debian/ * in build tools (meson, gcc etc) * in debhelper extensions * in debhelper * in wanna-build * in sbuild * in sbuild.conf in dsa-puppet * in sbuild overrides on buildds Some of the above will be faster to implement and some will be slower. The faster parts can possibly even make up for the slower parts, by for example doing the sbuild proposal in hooks until it is done in stable. Then there is the question of how the files get off the systems where builds happen (buildds, maintainer systems). Again, the faster/slower implementation implications exist here too. Then there is the question of how the files are further distributed from there and the question of how people access them. Then there is the question of whether any of the above will be implemented in a way that is useful solely to Debian, or in a more general way to all Debian or apt repository based distributions. Being able to publish build logs/artifacts seems like something other distros would be interested in. It sounds like at least the GCC maintainers want that for too Ubuntu at minimum. -- bye, pabs https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
