From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Lirzin Subject: [GSoC] Development of Cuirass. Date: Sun, 12 Mar 2017 15:49:47 +0100 Message-ID: <87tw6yim7o.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45540) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cn4oh-00035g-MX for guix-devel@gnu.org; Sun, 12 Mar 2017 10:49:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cn4og-0005Bc-Fa for guix-devel@gnu.org; Sun, 12 Mar 2017 10:49:51 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cn4og-0005BY-Bv for guix-devel@gnu.org; Sun, 12 Mar 2017 10:49:50 -0400 Received: from [2a01:e35:2ec2:e580:4a5d:60ff:fe57:52cd] (port=53710 helo=godel) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cn4of-0006v5-PN for guix-devel@gnu.org; Sun, 12 Mar 2017 10:49:50 -0400 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org Hi, Here is my proposal for the Google Summer of Code 2017. 1 Introduction =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 [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 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90 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 =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 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 =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80 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/12d71ee098c3eb84a9a5dc2419bd37a3b= 9e55dd2 3 Roadmap =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90 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. =E2=80=A2 From May 30 to June 26, I will work on the testing infrastructu= re,. =E2=80=A2 From June 27 to August 29, I will work on the HTTP API. 4 Feedback =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90 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 =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80 [1] [https://martinfowler.com/articles/continuousIntegration.html] [2] [https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.ht= m] --=20 Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37