[bug#32121] [PATCH 4/5] database: Call a specification 'jobset' instead of 'project'.

["Clément Lassieur" <clement@lassieur.org>]

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

> Clément Lassieur <clement@lassieur.org> skribis:
>
>> This removes the possibility to filter specifications by branch, because
>> branches were previously called 'jobset'.  But it doesn't matter because later
>> on, specifications will have as many branches as inputs.  And people should
>> filter by specification name instead.
>>
>> * doc/cuirass.texi (Build Information, Latest builds): Remove 'jobset',
>> replace 'project' with 'jobset'.
>> * src/cuirass/http.scm (build->hydra-build): Idem.
>> * tests/database.scm (db-get-builds): Idem.
>> * tests/http.scm (build-query-result, /api/latestbuilds?nr=1&jobset=guix,
>> /api/latestbuilds?nr=1&jobset=gnu): Idem.
>> * src/cuirass/database.scm (db-format-build, db-get-builds): Don't associate
>> builds with branches (which were called 'jobset' afterwards).
>> (db-get-builds): Remove the #:project filter.
>
> To make sure I understand correctly: it’ll still be possible to have,
> say, a “guix” job or a “modular” job built with several different
> branches, right?

Yes, you can have a specification "guix-modular-master" whose Guix
input's branch will be "master", and a specification
"guix-modular-core-updates" whose Guix input's branch will be
"core-updates".

> I think we should try to keep the HTTP API compatible with Hydra so we
> don’t break guix-hydra.el and possibly Tatiana’s work.

This will somehow break a minor part of Tatiana's work because the main
page will look like

--8<---------------cut here---------------start------------->8---
Projects/Specifications

| Name         | Branch       |
|--------------+--------------|
| guix-modular | master       |
| guix-modular | core-updates |
--8<---------------cut here---------------end--------------->8---

instead of

--8<---------------cut here---------------start------------->8---
Projects/Specifications

| Name                      |
|---------------------------|
| guix-modular-master       |
| guix-modular-core-updates |
--8<---------------cut here---------------end--------------->8---

But to me it's not a problem.  The branch is an implementation detail
and it's hidden.  Instead the information is in the name of the
specification.

Note that we will have control over the specification name, which wasn't
possible before because it was used by the evaluator.  Now the evaluator
uses the input's name.

It's not possible to keep the exact same API as hydra because we don't
have projects.  We could put everything under the same static project,
but it wouldn't really make sense.

However, we could still be able to bind a specification to a branch, but
that would require adding a 'guix-input' specification field, so that
the specification knows which input is the one whose branch should be
displayed.  I doubt it's worth it though.  Or we could replace the
'load-path-inputs' field with a 'guix-input' field.  That was kind of
the point of the 3rd part of my initial message[1].  Or, we could
automate things: find out from which input the Guix modules come.  That
would be a bit tricky.

WDYT?

Clément

[1]: https://lists.gnu.org/archive/html/guix-devel/2018-07/msg00023.html