artifacts from builds

Bug #1845159 reported by Matthias Klose
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
New
Undecided
Unassigned

Bug Description

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.

 - A common artifact for failing builds is the config.log file,
   dumped to stdout by debhelper. Same for some cmake logs.

 - 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.

   Work around for dejagnu (e.g. GCC) is to have a separate
   binary package holding all the test results. Not ideal as
   it costs archive space, and the logs have the same lifetime
   as the binary packages.

 - 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).

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), or even specific to the build (maybe only for the test rebuild).

Revision history for this message
Mattia Rizzolo (mapreri) wrote :

I suspect the first step to do anything about this is to get the builders (sbuild, pbuilder, etc) to agree on some sort of format to do this. It might be as easy as a simple "if after the build this directory exists and is non-empty, tar it up and copy it out of the chroot under this name derived from the original .dsc". (granted, it might be already be possible to do with some sorts of hooks and other flags (at least in pbuilder), but defining a clearer way to do this might not be a bad idea.

Matthias Klose (doko)
description: updated
tags: added: build-infrastructure lp-soyuz soyuz-build soyuz-publish
William Grant (wgrant)
tags: removed: build-infrastructure soyuz-publish
Revision history for this message
Simon McVittie (smcv) wrote :

Something very similar is being discussed on debian-devel:

https://lists.debian.org/debian-devel/2022/02/msg00216.html

and I've prototyped one possible approach in sbuild (see the thread for details).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.