Build Artifacts for buildds
The autopkg tests have the ability to collect some information in artifacts, collected in a tarball. That kind of feature could be useful for builds as well, both for failing and succeeding builds.
Currently there is the build log as the only artifact for builds, and people are trying to dump there everything which might be useful information:
- config.log files in case of a build failure (but often the wrong file is dumped when multiple config.log files are in the package).
- The preprocessed sources from GCC internal compiler errors, prefixed by the process id (sometimes goes wrong with parallel builds).
The other way to collect information is to include it in the binary packages, or to create a new binary package. This is usually done, when the needed information is too large, or unfit for dumping it in the build log.
- binutils-dev: both dejagnu log and sum files are stored in the binary package.
- gcc-N-test-results: Separate packages for dejagnu log and sum files.
However, these files are usually not created in a reproducible way. Having another storage location for this kind of information would make the source packages reproducible.
Artifacts to store
Artifacts should be stored for both successful and for failing builds.
- A common artifact for failing builds is the config.log file, dumped to stdout by debhelper. Same for some cmake logs. This also makes it possible to dump multiple config.log files, when these are present.
- A reproducible compiler error (ICE) produces a /tmp/cc*.out containing the preprocessed source. This is used to trim down the source to a test case to be submitted upstream. It's extra work to setup a local build for the target arch, and re-running the build. The current approach is to dump this file to stdout and hoping that we don't run too much in parallel ending up in garbled output.
- OpenJDK has a similar feature which produces hs_err dump files.
- Verbose test logs usually are not included in any package, but help diagnosing the problems without needing to do a local build. Many Gnome(?) builds have a verbose test log
- which has more information about the test runs. dejagnu based test suites produce *.sum and *.log files which contain all stdout/stderr output for a failing test case.
- For a test rebuild, I want to compare the config.h files generated by autoconf and look at the diff for each package (baseline build and test build).
- To compare native and cross builds, the config.status file(s) could be saved, and configuration differences be detected.
Triggers for artifacts
The trigger what to include in these artifacts is sometime the package itself (test logs), sometimes another package used for the build (e.g. GCC, OpenJDK), or even specific to the build (maybe only for the test rebuild).
ideas from the bof at dc24
- side idea: register sbom.debian.net and point that to buildinfos.debian.net
Design proposal
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, ..)
- the containering tool (sbuild, pbuilder, ...) at the end of the build, regardless of the result:
- check if the directory exists, and it's non-empty
- if true, tar it up
place the tar'ed-up artifacts in the usual results directory, with a predictive name ($pkg_$ver.artifacts.tar.xz?)
buildd/pybuildd will check if such file has been exported, if it is, then it will be uploaded to some service
- something as simple as an authenticate HTTP POST somewhere will do - no strong auth needed (right?)
- this new service will simply just accept whatever upload and store it
- possibly define an expiry rule for these artifacts to not hog all space needlessly