From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Cl=C3=A9ment?= Lassieur Subject: Re: 01/01: hydra: services: Fix Cuirass configuration. Date: Sat, 21 Jul 2018 01:07:46 +0200 Message-ID: <87o9f1mrp9.fsf@lassieur.org> References: <20180720182934.2138.94704@vcs0.savannah.gnu.org> <20180720182935.45B8E204A2@vcs0.savannah.gnu.org> <87muulob5x.fsf@gnu.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]:54005) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fgeVD-0002DO-5u for guix-devel@gnu.org; Fri, 20 Jul 2018 19:08:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fgeVB-0000M5-U1 for guix-devel@gnu.org; Fri, 20 Jul 2018 19:07:59 -0400 In-reply-to: <87muulob5x.fsf@gnu.org> 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org, guix-sysadmin@gnu.org Heya :-) 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. 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 lot = of work. > One question: could we have a single =E2=80=9Cguix=E2=80=9D input corresp= onding to > https://git=E2=80=A6/guix.git for the master branch? I suppose that shou= ld 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! > Anyway the database migration went smoothly and the new schema looks > much better. Thank you! HTH! Cl=C3=A9ment [1]: https://git.savannah.gnu.org/cgit/guix.git/tree/build-aux/hydra/guix-m= odular.scm#n66