Re: Standardized way of extracting additional build-time artefacts (was: Re: RFC: Standardizing source package artifacts build paths)
On Tue, 10 Mar 2020 at 07:19:59 +0000, Paul Wise wrote:
> On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote:
> > Standardized way of extracting additional build-time artefacts
>
> This reminds me of the BYHAND stuff, I forget how that works though.
I think how that works is that at the appropriate time during a successful
build, you run dpkg-distaddfile to insert extra entries that are not a
recognised file type (.deb, .udeb etc.) into debian/files?
The difference (as I understand it) is that BYHAND is for extra build
products that are listed in the .changes file and intended to be published
to Debian users via ftp.debian.org; whereas in this thread we're talking
about non-essential things that are produced as a side-effect of the
build, are potentially useful to Debian contributors for debugging and
analysis of the build process itself, but are not actually the "product".
Some important trade-offs are different. For example, for the build
products mentioned in the .changes file (whether .deb or BYHAND) we want
reproducible builds that don't capture unnecessary information like the
properties of the build system; whereas in build and test logs, we *do*
want to capture system-specific information in case it's relevant, for
example to help a Debian contributor to realise correlations like "this
test fails whenever we're building on a btrfs filesystem" that can help
them to find and fix bugs.
Similarly, we probably don't want to publish the build products to users
if the build(-time tests) failed (because we can't be confident that any
products that were already produced are good), although we might well
want to make them available through a contributor-oriented interface to
help to debug the failures; but we do want to publish build and test logs
to contributors, regardless of success or failure.
The .buildinfo file is arguably already in the same category as build
and test logs. We currently capture it in the .changes file and upload
it to ftp-master, but it isn't reproducible, and ftp-master doesn't
republish it through our user-facing interface (the archive). Ideally,
failed builds would capture their .buildinfo as well as their log for
subsequent analysis, although I don't know whether they actually do.
smcv
Reply to: