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