Hello Mathieu! Mathieu Lirzin <m...@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’.
