[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GSoC] Development of Cuirass.
[GSoC] Development of Cuirass.
Sun, 12 Mar 2017 15:49:47 +0100
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
Here is my proposal for the Google Summer of Code 2017.
[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 in software development. To achieve this
goal a lot of things remain to be done.
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. 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
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.
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.
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37