On Fri, Aug 02, 2024 at 11:01:24AM +0100, Simon McVittie wrote: > I also did some more concrete design and wrote a prototype - > <https://lists.debian.org/debian-devel/2022/02/msg00238.html> as revised > in <https://lists.debian.org/debian-devel/2022/02/msg00242.html>, and > <https://salsa.debian.org/debian/sbuild/-/merge_requests/14> - > although I never got as far as doing enough testing and polishing to get > it to a production-ready status. I'm sorry that this did not stay as my > top priority, but I can only have one top priority at a time.
Right, I read most of the emails in that thread and I did look at the
MR.
Unfortunately, I did so _after_ the BOF :\
> The artifacts that I'm primarily interested in are the results of failed
> testing
Right, that's also what we thought.
> But, when a test has failed, writing arbitrary imperative code to gather
> up the package-specific results (for example the images that were generated
> by the gtk4 test suite) is extra complexity for the package maintainer,
> which can have bugs, and is rarely tested because hopefully the tests
> usually pass. I dislike that as a pattern, and I'd strongly prefer a
> declarative syntax of some sort.
Consider that in my mind, most packages wouldn't have needed to write
any imperative code.
I was considering it for example within dh_auto_configure and
dh_auto_test, etc, those tools would be responsible for copying the
relevant test files into my proposed directory.
> In the design that I prototyped, it's declarative, loosely inspired by
> the equivalent Gitlab-CI feature:
>
> - the maintainer can write patterns into debian/build-artifacts for
> package-specific quirks like GTK's reftests
> (#-prefixed comments are allowed)
> - tools like debhelper can append patterns to debian/extra-build-artifacts,
> for example dh_auto_* in Meson mode should append "obj-*/meson-logs/*"
Well, I don't use debputy nor really understand it, so I don't
understand Niels' concerns.
But I could accept a file debian/extra-artifacts (for
maintainer-specified globs) and directory debian/extra-artifacts.d/
(for tools-provided globs). dh_auto_clean should (eventually) learn to
clean this directory.
And I suspect that packages that want to be dynamic in the content of
this archive can simply `echo path/to/stuff >>
debian/extra-artifacts.d/package` during the build instead of my
proposed `cp`.
Just, if we do we need to keep this as simple as possible as multiple
tools will try to parse it. I'd be ok with a plan list, at most accept
# at the start of a line for comments and empty lines.
> - the patterns reuse machine-readable debian/copyright syntax
> - as a result the -artifacts.tar.gz is always a subset of the build tree,
> and inherits its layout, same as Gitlab's artifacts.zip
This might not work as we want to be able to collect, for example, stuff
from /tmp/.
OTOH, this can be handled by doing proper subfolders in the tarball.
> and sbuild (or pbuilder if you prefer) is responsible for enumerating files
> matching the given patterns and packing them into a tarball.
I was trying to have something else do the enumeration and have
sbuild/pbuilder only do the packing, but I can be convinced in doing the
enumeration sure.
> > * place the tar'ed-up artifacts in the usual results directory, with
> > a predictive name (`$srcpkg_$ver_$arch.artifacts.tar.xz`?)
>
> I prototyped this as the same name as the log file, except replacing the
> .build extension with -artifacts.tar.gz (so the filename has a timestamp
> in it). My rationale for this choice is that when tests fail, it's common
> to retry the build to see whether the tests are reproducibly failing or
> just flaky, so we want to collect one blob of artifacts per attempt, the
> same way we collect one log per attempt.
>
> I don't know how the layers "above" sbuild such as buildd and wanna-build
> operate, and I don't have a way to test them, so my prototype stops at
> sbuild.
This can be left as an implementation detail of the build runner
(most likely, both sbuild and pbuilder will obtain a configuration knob
for this filename).
> > Matthias Klose would like to find a way to do something that at the end
> > of a build will look for and collect all the relevant files that are
> > produced during an ICE (for example all the pre-processor inputs, etc).
> > I'm not sure how to best solve it, but he was imagining a hook somewhere
> > (in dpkg?) that would look for them and copy them into the directory.
>
> Perhaps dpkg or dh_auto_build could append appropriate patterns to my
> debian/extra-build-artifacts on build failure, so that this hook would
> just be acting as an extension to the declarative mechanism?
Possibly. I suppose there could be a tool developed later that can be
used to search for any relevant file.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
