From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54822) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fduUg-0001TS-1E for guix-patches@gnu.org; Fri, 13 Jul 2018 05:36:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fduUc-0002mV-39 for guix-patches@gnu.org; Fri, 13 Jul 2018 05:36:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:49820) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fduUb-0002mN-UO for guix-patches@gnu.org; Fri, 13 Jul 2018 05:36:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fduUb-0004tY-Jd for guix-patches@gnu.org; Fri, 13 Jul 2018 05:36:01 -0400 Subject: [bug#32121] [PATCH 4/5] database: Call a specification 'jobset' instead of 'project'. Resent-Message-ID: References: <20180710230247.16639-1-clement@lassieur.org> <20180710230247.16639-4-clement@lassieur.org> <87muuvldrv.fsf@gnu.org> From: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur In-reply-to: <87muuvldrv.fsf@gnu.org> Date: Fri, 13 Jul 2018 11:35:03 +0200 Message-ID: <87wotz1nso.fsf@lassieur.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 32121@debbugs.gnu.org Ludovic Court=C3=A8s writes: > Cl=C3=A9ment Lassieur 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 sho= uld >> 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=3D1&jobset=3D= guix, >> /api/latestbuilds?nr=3D1&jobset=3Dgnu): Idem. >> * src/cuirass/database.scm (db-format-build, db-get-builds): Don't assoc= iate >> builds with branches (which were called 'jobset' afterwards). >> (db-get-builds): Remove the #:project filter. > > To make sure I understand correctly: it=E2=80=99ll still be possible to h= ave, > say, a =E2=80=9Cguix=E2=80=9D job or a =E2=80=9Cmodular=E2=80=9D job buil= t 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=E2=80=99t break guix-hydra.el and possibly Tatiana=E2=80=99s 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=C3=A9ment [1]: https://lists.gnu.org/archive/html/guix-devel/2018-07/msg00023.html