From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [GSoC] Rewrite Hydra to be more integrated with Guix. Date: Fri, 18 Mar 2016 22:02:53 +0100 Message-ID: <8760wjlcsi.fsf@gnu.org> References: <87bn6c944a.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]:54091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ah1Xy-0002eO-00 for guix-devel@gnu.org; Fri, 18 Mar 2016 17:03:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ah1Xs-0006Uq-TP for guix-devel@gnu.org; Fri, 18 Mar 2016 17:03:01 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ah1Xs-0006Uk-Pr for guix-devel@gnu.org; Fri, 18 Mar 2016 17:02:56 -0400 In-Reply-To: <87bn6c944a.fsf@gnu.org> (Mathieu Lirzin's message of "Thu, 17 Mar 2016 22:38:45 +0100") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Mathieu Lirzin Cc: guix-devel Hi! Mathieu Lirzin skribis: > This GSoC will not likely succeed in implementing every features Hydra > is currently providing. The objective is rather to create the basis > which will then allow further developpements to overcomes the present > difficulties. To achieve this the following milestones (suggested by > Ludo) will be followed: > > - Implementing a simple loop pulling Guix Git repository and building > every packages. >=20=20=20=20 > - Adding a =E2=80=9Cjob=E2=80=9D abstraction to be able to build differen= t Git branches. > > - Adding support for a database to keep track of the build results with > their associated commit, derivation and output. > > - Adding a API over HTTP to get the build results remotely (ideally > through an Emacs interface). > > - Adding support for configuring and launching jobs remotely. As we discussed earlier, I think this is pretty cool! :-) The nice thing is that it should be possible to incrementally improve things, always having something working and providing a real service. The idea is to assume we=E2=80=99d keep using =E2=80=98guix offload=E2=80= =99 to distribute work to the build machines. We know that it=E2=80=99s not perfect in terms of efficiency because every store item has to travel back and forth between the front-end and the build machines. However, there=E2=80=99s no fully-ba= ked design to improve on this AFAIK, so it=E2=80=99s reasonable to assume that improving that part is out of the scope of your project. Anyway, I think everyone is welcome to make suggestions on how this thing should work, or mistakes to avoid. Feedback from Mark, Andreas, and others who=E2=80=99ve dealt with Hydra or other CI systems is particula= rly welcome! Thoughts? Ludo=E2=80=99.