Re: [GSoC] Continuous integration tool à la Hydra.

[ludo@gnu.org (Ludovic Courtès)]

Hello Mathieu!

Mathieu Lirzin <mthl@gnu.org> skribis:

> 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.

Sounds good to me.

> '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.

When and if.  :-)

I’m saying “if” because while Hydra uses the database for inter-process
communication, I think we may as well use a message passing toolkit such
as ZeroMQ rather than abuse the database.  But that’s for later!

Looks like a good plan anyway!

Thank you,
Ludo’.