all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mathieu Lirzin <mthl@gnu.org>
To: guix-devel <guix-devel@gnu.org>
Subject: Re: [GSoC] Continuous integration tool à la Hydra.
Date: Tue, 21 Jun 2016 00:44:48 +0200	[thread overview]
Message-ID: <87h9cncwf3.fsf@gnu.org> (raw)
In-Reply-To: <871t4ksk0n.fsf@gnu.org> (Mathieu Lirzin's message of "Sun, 29 May 2016 22:10:16 +0200")

Hello Guix!

Here is a second update on my GSoC project after the first month.

As a reminder, Hydra (https://nixos.org/hydra/) is a Nix-based
continuous build system which is used by Guix to compile packages on
different platforms and to distribute packages substitutes.  The aim of
this project is to replace Hydra with a more integrated software written
in Guile, named “Cuirass”.

After providing a first basic evaluation loop described in my previous
mail, I have started thinking about the architecture of the global job
evaluation/compilation process in order to identify what type of data
structures would make sense.  It was not easy for me to reason about the
different layers of current Hydra usage in Guix, so it took me 2 weeks
to analyse it and provide a first decomposition of logic steps.  For now
this decomposition is:

  job-spec > job > build-result

where:
  
  - 'job-spec' defines all the information required by Cuirass to get
    the actual job definitions.  These information contains the
    repository type and url, the file and procedure name which yields a
    list of job, and the list of arguments passed to that procedure.

  - 'job' contains the derivation file name which describe all the
    dependencies.

  - 'build-result' contains the output obtained when realizing/building
    the derivation from a job + some logs.

'job-spec' and 'job' are already implemented in Cuirass. However
'build-result' will require a database to be useful.  Since I have no
experience with databases at all, this last week has been dedicated to
learn more about them, play with SQL queries, and use Guile-dbi and
Guile-sqlite3 bindings.  My plan is to use Sqlite first and eventually
switch to Postgresql later when concurrent writers would be critical.

The next step is to apply my newly acquired knowledge by allowing
'build-result' entries to be added to the database.  I will be AFK for 5
days so I will start working on that, next Sunday.

For those willing to follow my work, a Git repository is available here:

  https://notabug.org/mthl/cuirass

Everyone is of course welcome to provide any feedback.

Thanks.

-- 
Mathieu Lirzin

  parent reply	other threads:[~2016-06-20 22:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-29 20:10 [GSoC] Continuous integration tool à la Hydra Mathieu Lirzin
2016-05-30 21:34 ` Ludovic Courtès
2016-05-30 21:54 ` Ludovic Courtès
2016-06-20 22:44 ` Mathieu Lirzin [this message]
2016-06-24 12:42   ` Ludovic Courtès
2016-07-25  0:30 ` Mathieu Lirzin
2016-07-25 21:36   ` Ludovic Courtès
2016-07-27 14:28     ` Mathieu Lirzin
2016-07-28 12:38       ` Ludovic Courtès
2016-07-29 11:20     ` Florian Paul Schmidt
2016-07-29 19:26       ` Mathieu Lirzin
2016-07-30 22:49         ` Ludovic Courtès
2016-07-31  2:05           ` 'guix environment' as a build tool. (was: [GSoC] Continuous integration tool à la Hydra.) Mathieu Lirzin
2016-07-31  2:20             ` Thompson, David
2016-07-31  4:17               ` 'guix environment' as a build tool Mathieu Lirzin
2016-07-31 13:55               ` Ludovic Courtès
2016-07-31 14:07                 ` Thompson, David
2016-07-31 20:09                   ` Ludovic Courtès
2016-07-31 11:13             ` Ludovic Courtès
2016-07-31  7:09         ` [GSoC] Continuous integration tool à la Hydra Florian Paul Schmidt
2016-07-31 12:03           ` Mathieu Lirzin
2016-08-01 18:55             ` Florian Paul Schmidt
  -- strict thread matches above, loose matches on Subject: below --
2016-08-06 11:05 David Craven
2016-08-06 16:19 ` Mark H Weaver
2016-08-06 16:23   ` David Craven
2016-08-06 16:58     ` David Craven
2016-08-06 23:45 ` Mathieu Lirzin

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

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

  git send-email \
    --in-reply-to=87h9cncwf3.fsf@gnu.org \
    --to=mthl@gnu.org \
    --cc=guix-devel@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.