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