Re: Bringing substitutes from the Guix Build Coordinator to users

["Ludovic Courtès" <ludo@gnu.org>]

Hi Chris,

Christopher Baines <mail@cbaines.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> My understanding is that, to build substitutes, we need more than the
>> Coordinator; we also need something to perform evaluations, similar to
>> the “top half” of Cuirass and the Data Service, right?  How would you
>> envision setting it up?
>
> The queue builds script bundled in with the guix-build-coordinator seems
> to work fine, that's how bayfront is currently set up:
>
>   (service guix-build-coordinator-queue-builds-service-type
>          (guix-build-coordinator-queue-builds-configuration
>           (systems '("x86_64-linux"))))
>
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm#n781

Oh, right.

[...]

> There's been some progress, albeit slow progress with the patch testing
> setup I've been working on, but I've been viewing that as a way to test
> branches as well. Given changes happen through patches and branches, I
> think this makes sense, and I think the Guix Data Service has some nice
> features for helping with this, like comparing two revisions and working
> out what breakages have occurred.
>
> However, with patches and branches, this is very much a continuous
> integration tooling issue, much more than substitutes. Cuirass is
> already building branches, and it's been gaining features previously
> found in the Guix Data Service, like tracking the history of which
> derivations relate to which revision, and separating out packages from
> system tests so that it's easier to look at them.

Yes, though to be fair, the system test separation is a separate jobset,
not a “feature” of Cuirass.

From what I can see Cuirass is in the footsteps of Hydra in terms of
design, which was somewhat ad-hoc at times, focusing on answering
developer questions.

> As people are going to Cuirass to look at the build status for packages,
> system tests and various branches, the problem is similar to that of
> substitutes. It doesn't matter if the Guix Build Coordinator seems to do
> some things better, when the question comes up about whether something
> has built yet, or whether a branch is ready to merge, Cuirass on
> ci.guix.gnu.org is where people are going, and that seems unlikely to
> change (at least less likely than the setup for providing substitutes).
>
> The Guix Data Service in the center, making it easier to do various
> things by providing the data, this was the idea when it started, but the
> reality recently is that strategy hasn't been paying off.

The Data Service provides a wealth of information that’s underused!

I think addressing the interface issue (be it web UI or JSON + CLI) is
high priority so we can all start taking advantage of the Data Service.
The current interface is generic enough that it allows you to see
everything, from lint warnings to version changes to reproducitility
rates.

We could have interfaces that answer very specific needs:

  • Which packages are broken on x86_64?

  • How does branch X compare to branch Y in terms of build failures?

  • Which packages are not reproducible?

  • Which packages are “flaky”?

I know all this information is already available from the web UI, but
because it’s generic, it can be hard to find out how to answer very
concrete issues like this.

A QA entry point like you proposed in the thread you mentioned¹ could
certainly help.  A reproducibility entry point would be nice too.  A
package browser for guix.gnu.org like the one Danjela worked on would be
great too, possibly with version browsing facilities.  And Guix Weekly
News!  And the security tracker!  :-)

¹ https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00096.html

It seems to me that all that hard work is already done and what I
describe above are rather low-hanging fruits.

Taking Conway’s law into account, we may find it easier to recruit if as
much as possible takes place here, things get deployed behind
*.guix.gnu.org, and relevant bits are made part of Guix proper.  And
also, we must regularly advertise progress; one blog post in all of the
Guix Data Service’s lifetime is not enough.  :-)

Thoughts?

Ludo’.