[GSoC] Development of Cuirass.

[Mathieu Lirzin]

Hi,

Here is my proposal for the Google Summer of Code 2017.

1 Introduction
══════════════

  [Cuirass] is a build automation server using GNU Guix package manager.
  This project has started last year as a Google Summer of Code (GSoC)
  with the goal of replacing [Hydra] which is the continous build server
  used by Nix and Guix to provide package substitutes.  Cuirass intends
  to be a multi-purpose build automation server.  It aims at allowing
  users to have their own build farm for packages they maintain outside
  of Guix tree, and at providing a tool for applying the principle of
  continuous integration[1] in software development.  To achieve this
  goal a lot of things remain to be done.


  [Cuirass] https://notabug.org/mthl/cuirass

  [Hydra] https://nixos.org/hydra/


2 Proposal
══════════

  The project is the continuation of last year work, and is separated in
  two parts.  The first part is to improve the testing infrastructure.
  The second one is about providing a more complete HTTP API.


2.1 The testing infrastructure
──────────────────────────────

  Currently Cuirass is providing a small test suite consisting only of
  unit tests.  The integration tests are done manually with basic
  examples consisting in building small packages such as GNU Hello.
  This is not good, because actual packages take a consequent time to
  compile, and testing only basic examples leaves the interesting
  complex case out of the scope of testing.  The worst is that the
  result depend on the phase of the moon since every commit in Guix can
  potentially break the build.

  The idea is to take inspiration from the Guix test suite by providing
  tiny mocked packages that will help having lightweight build
  specifications.  Those tests require launching another instance of the
  `guix-daemon' with a local temporary store.


2.2 HTTP API
────────────

  Since commit [12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2] Cuirass has a
  web server which is running in a separate thread of the `cuirass'
  process.  However the resources it provides are pretty limited since
  you can only query the lists of specifications currently watched.
  This is done with the `/specifications' or `/jobsets' resource names.
  "Jobsets" is the terminology used by Hydra and is used here for
  compatibility with its HTTP API.

  The principal objective of this part is to provide a more complete API
  which allows users to query the build results and to add their
  specifications to the current set.  The design of this API will apply
  the principles of the Representational State Transfert (REST)
  architectural pattern[2].  Sensitive requests should be done with an
  authentification mechanism which is not determined yet.  I currently
  have no experience with any and lack the knowledge to properly choose
  one.


  [12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2]
  
https://notabug.org/mthl/cuirass/commit/12d71ee098c3eb84a9a5dc2419bd37a3b9e55dd2


3 Roadmap
═════════

  This roadmap lacks details about the concrete tasks and its associated
  timeline.  However I prefer having some feedback about this proposal
  first, before providing a complete roadmap.

  • From May 30 to June 26, I will work on the testing infrastructure,.
  • From June 27 to August 29, I will work on the HTTP API.


4 Feedback
══════════

  Some people have expressed their interest in having a Web /frontend/
  for Cuirass.  To avoid possible confusions I have no plan in working
  on it this summer.  While this would be a very valuable effort, I
  don't feel up to the task.

  Regarding the Authentification mechanism, any enlighten advice or
  resource would be welcome.  If anybody think of other important tasks
  that need to be addressed, please share.



Footnotes
─────────

[1] [https://martinfowler.com/articles/continuousIntegration.html]

[2] [https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm]

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37