From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: 01/01: hydra: services: Fix Cuirass configuration. Date: Mon, 23 Jul 2018 14:58:10 +0200 Message-ID: <87va96rtwd.fsf@gnu.org> References: <20180720182934.2138.94704@vcs0.savannah.gnu.org> <20180720182935.45B8E204A2@vcs0.savannah.gnu.org> <87muulob5x.fsf@gnu.org> <87o9f1mrp9.fsf@lassieur.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fhaPr-0005r1-RA for guix-devel@gnu.org; Mon, 23 Jul 2018 08:58:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fhaPq-0008D0-S9 for guix-devel@gnu.org; Mon, 23 Jul 2018 08:58:19 -0400 In-Reply-To: <87o9f1mrp9.fsf@lassieur.org> (=?utf-8?Q?=22Cl=C3=A9ment?= Lassieur"'s message of "Sat, 21 Jul 2018 01:07:46 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: =?utf-8?Q?Cl=C3=A9ment?= Lassieur Cc: guix-devel@gnu.org, guix-sysadmin@gnu.org Hey! Cl=C3=A9ment Lassieur skribis: > Ludovic Court=C3=A8s writes: > >> Thanks a lot for fixing it! Cuirass is back up and running now on >> berlin. > > Yay! > > One note though: Cuirass reads the config once, and only adds the > specifications whose name isn't already in the database. So it would > have worked if you had used '() as a specification list, because the > database was in a consistent state (thanks to the upgrade). > > The four specifications I added are totally useless, except for their > names, and the fact that they describe the database. What I mean is > that if you change them it won't have any effect. But if you change > their name, Cuirass will think they are new and try to add them to the > database. Yeah I know, terrible. > This behaviour is terrible, because it means the configuration is non > deterministic. It would be great to add a mechanism that detects > specification changes, and updates the database accordingly. But I'm > not sure it's feasible. Another solution would be to edit the database > through a web interface, =C3=A0 la hydra :-), but that would require a lo= t of > work. In practice I have to admit that I add, remove, or modify specs through the sqlite3 command line, and that=E2=80=99s okayish (did you know that SQL= was initially designed to be *the* user interface to the database? :-)). Another approach would be to have part of our database available in Git instead of in an actual database. So Cuirass would pull its specs from a Git repo and that=E2=80=99s it. That=E2=80=99s less work than writing an= HTTP interface, and that=E2=80=99s more flexible/convenient. >> One question: could we have a single =E2=80=9Cguix=E2=80=9D input corres= ponding to >> https://git=E2=80=A6/guix.git for the master branch? I suppose that sho= uld work >> in theory? > > The inputs can all be named "guix", if that's what you mean. Actually, > they can all be named the way you want, except the 'guix-modular' ones > that can only be named "guix" or "guix-modular"[1]. I think we should > add an ad-hoc 'key' field to avoid that restriction. That 'key' field > would be the key used by the evaluator to access the 'guix-checkout'. > > As for allowing the same input to be used by several specifications > (that is, a N - N relationship between the Inputs and the Specifications > tables), it is possible, but it would require deep changes: each input > would need to have a associated stamp in the database, and when the > input changes, the evaluation of all its specs would need to be > triggered. It would be more efficient though, because it would reduce > the number of 'git pull'. > > I chose to implement a N - 1 relationship between Inputs and > Specifications because that's how Hydra does, it requires less code > changes, and in most cases several specifications won't use the exact > same inputs. But we can definitely improve it if you think it's worth > it! OK. Well that=E2=80=99s good enough for now! Thanks for explaining! Ludo=E2=80=99.