Re: Jenkins-based Continuous

[Colin Walters <walters verbum org>]

On Thu, Oct 16, 2014, at 06:38 AM, Vadim Rutkovsky wrote:
> Hi,
>
> I was playing with Jenkins and Continuous recently and got some interesting results, which might improve 
> current situation with UI. 
> Jenkins takes care of many minor aspects current http://build.gnome.org is missing like storing task 
> history, many plugins, configuration without committing to git etc.
> The heart of it is still the same 'ostbuild make', but with different params and overall workflow.
>
> The workflow on Jenkins will change a bit:

You're doing some great work here, and I don't want it to be stalled.  I've been thinking about this in the 
background, and here's my current conclusion:

- I'm OK with using Jenkins as a control framework for *tests*, after the build
- I do not want actual *builds* (i.e. git -> tree) to involve Jenkins

To implement this, we should run the tests and builds as separate uids on the server.  Splitting up the build 
and test environment and having them be separate "processes" (containers?) will allow us a lot more agility 
on the test side too.  We can push updates to the test suite faster.

This model addresses my concerns with security - if the Jenkins web frontend is compromised[1], it doesn't 
allow an attacker to insert malicious binaries.  It also clearly avoids a dependency on Jenkins for 
developers doing builds locally.

*However* there will be a need for bidirectional communication.  Right now, when the smoketest passes, we tag 
it as e.g. "gnome-continuous/smoketested/x86_64-devel-debug".  So the build/release side will need to offer 
an API for testing systems.

Here's a potential rough outline:
 - Take all of the testing and web UI code out of gnome-continuous, create a new module gnome-continuous-tests
 - Allocate a new UID on build.gnome.org
 - Add a private message bus (I'm currently thinking http://stomp.github.io/)
 - Define a new module for a unified web frontend that shows combined build and test status 
(gnome-continuous-web?)

[1] Writing dynamic web frontends is *hard*.   You have to be *extremely paranoid* when parsing input.  I 
don't trust myself to do it.  And Jenkins has a history here, e.g.:

https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2014-10-01

SECURITY-150/CVE-2014-3666 (remote code execution from CLI)

Unauthenticated user can execute arbitrary code on Jenkins master by sending carefully crafted packets over 
the CLI channel.