Andreas Enge <andreas@enge.fr> writes:

> So it would be nice if someone could set up a more complete job for
> core-updates on cuirass or QA, and maybe write up a how-to to see which
> packages work and which ones need more love, preferably by architecture.
> (Without offense, I honestly do not see what
>    https://ci.guix.gnu.org/jobset/core-updates
> tells me. There is one evaluation with 290 succeeding and 300 failing
> builds, and another one with 7 succeeding and 4 failing builds. Or are
> these only the newly succeeding or failing builds? There is the dashboard
> which gives visual clues, but can it be used to extract a list of
> "originally failing" packages, in the sense that the compilation fails
> itself instead of just a dependency - otherwise said, the failures highest
> up in the package graph, which need to be worked on? On QA I think so far
> there is nothing for core-updates, and the bordeaux build farm probably
> could not keep up while also working on issues from the tracker. Generally
> speaking, I think we need more tooling and documentation of the tooling if
> feature branches are to become a thing.)

I configured QA to submit builds for core-updates a little while back,
currently it requires a code change [1].

1: https://git.cbaines.net/guix/qa-frontpage/commit/?id=39e9ec627faca95a7b43ff91e195ca9ab9846bf3

The builds are currently low priority compared to the patch testing ones
though, and there are more of these since raising the limit [2].

2: https://git.cbaines.net/guix/qa-frontpage/commit/?id=cd5687118de9858ac714d55800c2648969dbbb48

You can see the substitute availability for core-updates here [3].

3: https://data.qa.guix.gnu.org/repository/2/branch/core-updates/latest-processed-revision/package-substitute-availability

It's possible to alter the priority for builds, so we could try and get
some to happen for core-updates.

I'm going to try and put some more time in to getting the qa-frontpage
to display some useful information about branches.

Thanks,

Chris