unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Mathieu Lirzin <mthl@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: [GSoC] Rewrite Hydra to be more integrated with Guix.
Date: Fri, 18 Mar 2016 22:02:53 +0100	[thread overview]
Message-ID: <8760wjlcsi.fsf@gnu.org> (raw)
In-Reply-To: <87bn6c944a.fsf@gnu.org> (Mathieu Lirzin's message of "Thu, 17 Mar 2016 22:38:45 +0100")

Hi!

Mathieu Lirzin <mthl@gnu.org> 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.
>    
> - Adding a “job” abstraction to be able to build different 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’d keep using ‘guix offload’ to distribute work
to the build machines.  We know that it’s 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’s no fully-baked
design to improve on this AFAIK, so it’s 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’ve dealt with Hydra or other CI systems is particularly
welcome!

Thoughts?

Ludo’.

  parent reply	other threads:[~2016-03-18 21:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-17 21:38 [GSoC] Rewrite Hydra to be more integrated with Guix Mathieu Lirzin
2016-03-18  8:29 ` Alex Kost
2016-03-18 20:55   ` Ludovic Courtès
2016-03-19  7:48     ` Alex Kost
2016-03-19 20:59       ` Ludovic Courtès
2016-03-18 21:02 ` Ludovic Courtès [this message]
2016-03-22 21:31 ` Andreas Enge
2016-03-23 14:08   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8760wjlcsi.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=mthl@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).