Simon McVittie:
On Fri, 02 Aug 2024 at 16:40:15 +0900, Mattia Rizzolo wrote:
[...]
* 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!)
I agree with Simon on this part. This logic will rarely be tested by the maintainer, so we should minimize the amount of code a maintainer should
do for this.
Thanks to previous design work, I think this problem is now largely down
to various tool writers (pbuilder/sbuilder + the build helper tooling)
doing a prototype of it and letting it loose.
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)
I am a bit tempted to keep this one out of the spec and leave it to the build-helper to define it. I find that files in `debian/` are not very discoverable and they are harder to support properly in tooling like
`debputy lsp server`. Each file format requires extra setup and there is
not a good way to announce they exist unlike fields in `debian/control`.
For `debputy` based packages, I would prefer to have this in the `debian/debputy.manifest`, since that will enable me to guide the
packager to its existence and provide on-line documentation for it.
- tools like debhelper can append patterns to debian/extra-build-artifacts,
for example dh_auto_* in Meson mode should append "obj-*/meson-logs/*"
As a minor detail, I would make this a .d directory where tools can
write files in. This avoids issues with concurrency control. It is
possible to run `dh_auto_configure` in parallel. That is not the only
way concurrency issues could happen and I am already not excited about
solving concurrency issues even assuming debhelper is the only source of
this problem (hint: it won't be). Therefore, a directory and tools using
random generated filenames. Be that standard `mktemp -p $DIR` or even
just uuidv4'ing the filename. Either way the concurrency issue would be
reduced to "an already solved problem".
Secondly, I would want clarity on how this directory is created and
cleaned up. Personally, I do non-chroot host builds all the time for
rapid development and I would mind the clutter if every build leaves
this directory behind - which realistically will end up in the
`.debian.tar.gz` at some point if not cleaned by the build process
itself. At the same time, I quite understand always wanting the
directory for CI/buildd builds.
An alternative here is that the build tool exports an ENV variable
for the directory to put these "extra-build-artifacts" into and is then responsible for cleaning it up. Since the ENV var would only be exported
when you wrap your build in sbuild/pbuilder, the clutter would not occur.
However, I think further detailing on this part is between me and
whoever is going to do it on the pbuilder/sbuild side.
- 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 :-)
This all sounds good to me. Mattia's wiki page does list "A reproducible compiler error (ICE) produces a /tmp/cc*.out containing the preprocessed source.", which might need some tweaking compared to the "the
-artifacts.tar.gz is always a subset of the build tree". But again, I
sure we can figure out a solution to this problem in the practical
coding - such as requiring the tool to copy it into the build tree first
(which in turn requires the tool to ensure it is cleaned by `d/rules
clean`, but presumably a trivially solvable problem).
and sbuild (or pbuilder if you prefer) is responsible for enumerating files matching the given patterns and packing them into a tarball.
I very much like this part of the design. They can delegate to a common
tool to share the implementation without us worrying about build-depends contamination (which would be a issue for build-helpers). Since the
logic would be able to run on the host system rather than in the chroot,
we also do not have to worry about the installability being trashed in
sid and temporarily neuter the log fetching ability.
[...]
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)
I am sure we can figure out a solution to this on top of the protocol. I
see arguments for putting it in pbuilder/sbuild and for putting it into
the build helper. I think this boils down to the use-case would be
invoked in practice where exactly the logic goes. But I feel it is again
a problem that is very solvable once we have the infrastructure in-place
and a proper idea of how to play out the use-case.
Dear, sbuild/pbuilder maintainers, feel free to give me a holler on this
and lets fix this with a prototype somewhere.
Best regards,
Niels
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)