From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Nieuwenhuizen Subject: Re: using Cuirass to track a guix packages' git Date: Fri, 23 Sep 2016 17:39:35 +0200 Message-ID: <87shsqbp6w.fsf@gnu.org> References: <87fup0rqwz.fsf@gnu.org> <8760pn7ftf.fsf@gnu.org> <871t0adalz.fsf@gnu.org> <87r38ay6xx.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]:47772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnSa3-0008PL-Ne for guix-devel@gnu.org; Fri, 23 Sep 2016 11:40:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bnSZy-0008Hc-NO for guix-devel@gnu.org; Fri, 23 Sep 2016 11:40:02 -0400 In-Reply-To: <87r38ay6xx.fsf@gnu.org> (Mathieu Lirzin's message of "Fri, 23 Sep 2016 17:25:14 +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: Mathieu Lirzin Cc: guix-devel@gnu.org Mathieu Lirzin writes: > Intuitively I would prefer "#:compile?" but both are OK, so we can stick > with "#:no-compile?" if that's more convenient. Yes, me too. Let's see where this goes, it can prolly be changed easily later. >>> Can you send the updated patches? >> >> Sure, find attached. > > Pushed with minor cosmetic changes. :) Nice changes. Thanks. > Given the current state of Cuirass, I think it is OK to not provide > documentation while experimenting. Ok. >> Thanks! I'd really love to get a working Guix-based ci system and >> Cuirass is already very close to the minimal set that I need. I have >> a working patch to add building of VMs (a la hydra/guix-system.scm) but >> it needs a bit of cleanup work. > > Nice! I figure we experiment and maintain this in Cuirass and move into Guix again later. > There is a basic Guile Web server which is runnable via > 'run-cuirass-server' procedure. There is only one JSON ressource which > is accessible from "/specifications" and "/jobsets" routes. To use the > server you have to parameterize the '%package-database' parameter to > point to an SQLite file with specifications in it. Yes, I think I found this, I can see json in my browser window...but that's not really a web view yet (no criticism, I'm just wondering...) > What needs to be done is to provide more JSON ressources (inspired by > Hydra API) by translating request to SQL queries. A command line > interface would be a nice addition too. If this is inspired by Hydra does it mean you plan to somehow use (parts of?) the Hydra web engine to present views using this json? Greetings, Jan. --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.nl= =20=20