On Fri, 02 Aug 2024 at 16:40:15 +0900, Mattia Rizzolo wrote: > Lastly I think https://lists.debian.org/debian-devel/2022/02/msg00216.html > to which Simon had a quite nice answer.
I also did some more concrete design and wrote a prototype - <https://lists.debian.org/debian-devel/2022/02/msg00238.html> as revised in <https://lists.debian.org/debian-devel/2022/02/msg00242.html>, and <https://salsa.debian.org/debian/sbuild/-/merge_requests/14> - although I never got as far as doing enough testing and polishing to get it to a production-ready status. I'm sorry that this did not stay as my top priority, but I can only have one top priority at a time. (There is also some good input from Paul Wise in the 2022 thread) > * decide on a directory name (`./debian/export_artifacts/`?) > * the build process will dump any files that could be interesting to > export in there (no decision if/how to define the structure within > this directory) > * potentially, all `dh_*` could copy there whatever is relevant to > them (i.e., `dh_auto_configure` could export configure logs, > `dh_auto_test` the various test logs, ..) My concern about this, and the reason my prototype doesn't work this way, is what I said in <https://lists.debian.org/debian-devel/2022/02/msg00242.html>. The artifacts that I'm primarily interested in are the results of failed testing, because at the moment librsvg and gtk4 have to exfiltrate their failed test results (some of which are in the form of images, because these are GUI libraries) by uuencoding PNG files and writing the result to the log, and that's both inconvenient and inefficient. But, when a test has failed, writing arbitrary imperative code to gather up the package-specific results (for example the images that were generated by the gtk4 test suite) is extra complexity for the package maintainer, which can have bugs, and is rarely tested because hopefully the tests usually pass. I dislike that as a pattern, and I'd strongly prefer a declarative syntax of some sort. (Take a look at all the ad-hoc scripting that src:gtk4 has around what to do after test failures and I think you'll see what I mean!) In the design that I prototyped, it's declarative, loosely inspired by the equivalent Gitlab-CI feature: - the maintainer can write patterns into debian/build-artifacts for package-specific quirks like GTK's reftests (#-prefixed comments are allowed) - tools like debhelper can append patterns to debian/extra-build-artifacts, for example dh_auto_* in Meson mode should append "obj-*/meson-logs/*" - the buildd operator can configure $artifact_patterns in .sbuildrc if they want to (I'm unsure how useful this genuinely is, but maintainers running sbuild locally might find it more convenient than editing the source package during ad-hoc debugging) - the patterns reuse machine-readable debian/copyright syntax - as a result the -artifacts.tar.gz is always a subset of the build tree, and inherits its layout, same as Gitlab's artifacts.zip - if a sufficiently desperate maintainer really wants to, they can tar up the entire build tree by specifying a broad enough pattern like '*', although this should be discouraged when building larger packages :-) and sbuild (or pbuilder if you prefer) is responsible for enumerating files matching the given patterns and packing them into a tarball. > * place the tar'ed-up artifacts in the usual results directory, with > a predictive name (`$srcpkg_$ver_$arch.artifacts.tar.xz`?) I prototyped this as the same name as the log file, except replacing the .build extension with -artifacts.tar.gz (so the filename has a timestamp in it). My rationale for this choice is that when tests fail, it's common to retry the build to see whether the tests are reproducibly failing or just flaky, so we want to collect one blob of artifacts per attempt, the same way we collect one log per attempt. I don't know how the layers "above" sbuild such as buildd and wanna-build operate, and I don't have a way to test them, so my prototype stops at sbuild. > Matthias Klose would like to find a way to do something that at the end > of a build will look for and collect all the relevant files that are > produced during an ICE (for example all the pre-processor inputs, etc). > I'm not sure how to best solve it, but he was imagining a hook somewhere > (in dpkg?) that would look for them and copy them into the directory. If we need an imperative hooks mechanism for something like this, then so be it, but I'd really prefer executing arbitrary code to be the uncommon case rather than something we always have to do. Perhaps dpkg or dh_auto_build could append appropriate patterns to my debian/extra-build-artifacts on build failure, so that this hook would just be acting as an extension to the declarative mechanism? smcv (not at Debconf)
