Re: RFC: Standardizing source package artifacts build paths

[Simon McVittie <smcv@debian.org>]

On Mon, 09 Mar 2020 at 20:45:13 +0100, Niels Thykier wrote:
> Simon McVittie:
> > For example, dpkg-buildpackage could perhaps read one glob per
> > line from debian/artifacts and hardlink matched files (if any) into
> > debian/.build/artifacts for collection by a "larger" framework like
> > sbuild or pbuilder, or individual packages could copy/link files into there
> > as they go, or debhelper build-system classes like Autotools and Meson
> > could know the names of common log files from their build system, or
> > some combination of those.
> 
> Though, can you elaborate a bit on why the above approach would be
> better than a standard ENV variable a la AUTOPKGTEST_ARTIFACTS and some
> easy way to declare additional artifacts to be extracted?

Mainly, I'd prefer something declarative with glob patterns (a bit like
debian/clean or Gitlab-CI's artifacts:paths) rather than having to write
logic like these pseudo-patches:

    -./configure
    +if ./configure; then
    +    : # OK
    +else
    +    error=$?
    +    if [ -n "$DPKG_ARTIFACTS" ]; then
    +        cp config.log "$DPKG_ARTIFACTS/config.log" || :
    +    fi
    +    exit "$error"
    +fi

    -make check
    +if make check; then
    +    : # OK
    +else
    +    error=$?
    +    if [ -n "$DPKG_ARTIFACTS" ]; then
    +        find tests/ -name '*.log' | something something xargs cp
    +    fi
    +    exit "$error"
    +fi

(doubly so if I have to sprinkle backslashes, tabs and double $ over
it to make it a valid Makefile), and I'm sure you think similarly from
the perspective of writing debhelper buildsystem classes.

In particular, if you want to capture Automake test logs without also
capturing unrelated files that happen to be named *.log, as far as
I'm aware there is no general way to do that without knowledge of the
specific package and how its tests are named or arranged, so individual
maintainers are likely to have to be involved in designating which logs
are of interest.

I don't have any particular opinion on whether artifacts should be
collected into debian/.build/artifacts/, into $DPKG_ARTIFACTS/, or
directly into some sort of archive (Gitlab and Jenkins seem to use zip
files, which have the advantage of being seekable, so web frontends
can presumably read individual logs directly out of the zip file if
that's desirable).

    smcv