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

> Christopher Baines <mail@cbaines.net> skribis:
>
>> * gnu/services/guix.scm (<guix-build-coordinator-queue-builds-configuration>):
>> New record type.
>> (guix-build-coordinator-queue-builds-configuration,
>> guix-build-coordinator-queue-builds-configuration?,
>> guix-build-coordinator-queue-builds-configuration-package,
>> guix-build-coordinator-queue-builds-configuration-user,
>> guix-build-coordinator-queue-builds-coordinator,
>> guix-build-coordinator-queue-builds-configuration-systems,
>> guix-build-coordinator-queue-builds-configuration-system-and-targets,
>> guix-build-coordinator-queue-builds-configuration-guix-data-service,
>> guix-build-coordinator-queue-builds-configuration-processed-commits-file,
>> guix-build-coordinator-queue-builds-shepherd-services,
>> guix-build-coordinator-queue-builds-activation,
>> guix-build-coordinator-queue-builds-account): New procedures.
>> (guix-build-coordinator-queue-builds-service-type): New variable.
>
> [...]
>
>> +@defvar {Scheme Variable} guix-build-coordinator-queue-builds-service-type
>> +Service type for the
>> +guix-build-coordinator-queue-builds-from-guix-data-service script.  Its
>
> Oh! :-)
>
> ‘guix-build-queue’ maybe?  Because after all, it can queue builds coming
> from anywhere, not just from the Data Service, right?
>
> It’d be nice to add a sentence or two explaining how the “queue” fits in
> the big picture (I’m not quite sure :-)).

So, this got me thinking a bit, maybe this script should actually exist
outside of the guix-build-coordinator repository...

You can run `guix-build-coordinator build ...` to build a derivation,
and what this does is just make the relevant HTTP request to the
coordinator.

What this script does is just fetch derivation names from an instance of
the Guix Data Service, and ask the Guix Build Coordinator to build
them.

>> +@item @code{systems-and-targets} (default: @code{#f})
>> +An association list of system and target pairs for which to fetch
>> +derivations to build.
>
> Cross-compilation target triplets are a notion that’s not available at
> the derivation level; it only exists for packages.
>
> Are we mixing things here?

This setting is basically configuing the query parameters to use for
this page for example [1]. You're right that it's not available at the
derivation level, but you can ask the Guix Data Service for derivations
for packages which were computed for a specific system and target.

1: http://data.guix.gnu.org/revision/70ef8b24550c54cc8e9f20026bfd24b8680499b4/package-derivations

>> +@item @code{guix-data-service} (default: @code{"https://data.guix.gnu.org"})
>> +The Guix Data Service instance from which to query to find out about
>> +derivations to build.
>
> Ah so the queue pulls from the Data Service.  Got it!

I wouldn't read too much in to "queue" in the name here, "submit" might
be a better word to use, since that's the term used on the Guix Build
Coordinator side. There's also nothing resemling a queue anywhere...

>> +@item @code{processed-commits-file} (default: @code{"/var/lib/guix-build-coordinator-queue-builds/processed-commits"})
>> +A file to record which commits have been processed, to avoid needlessly
>> +processing them again if the service is restarted.
>
> Maybe in /var/cache by default, no?

Ah, yeah, I've changed it to be in /var/cache, as that's fine.

>> +  (processed-commits-file
>> +   guix-build-coordinator-queue-builds-configuration-processed-commits-file
>> +   (default "/var/lib/guix-build-coordinator-queue-builds/processed-commits")))
>
> Maybe “state-file”?  In addition to saving space :-), it’d leave room
> for additional bits of state.

Currently, it's just a file with each commit on its own line. Given
that, if there's a need to store more state, it might just end up in
different files. If that happens, this setting could become a directory,
rather than a specific file to avoid adding extra configuration options.