Re: Jenkins-based Continuous

[Colin Walters <walters verbum org>]

On Thu, Oct 16, 2014, at 07:38 AM, Vadim Rutkovsky wrote:
>  3. Each component is build built separately.

I don't understand that - with Continuous I was intentionally trying to
get away from the "package" mindset of lots of individual little
fiefdoms.

In reality things *do* depend on each other.  When glib changes, that
can affect gtk+, gtk+ changes affect apps, etc.  And thus it makes sense
to build and test wholes, not parts.

Both build time and runtime.  When glib changes the gtk+ buildroot needs
to be updated.

> fter each build the task
>  builds a runtime image and runs smoketests.

Hm, is this using jenkins master/slave, so this gets parallelized across
hosts?

>  5. As all component tasks are scripted, any commit to gnome-continuous
>  repo will reconfigure tasks automatically - this would allow seamless
>  tagging component and their adding/removal.

Interesting.

>  1. If one component fails to build the tasks won't get stopped

There's a spectrum here.  If gtk+ fails to build, the whole train should
stop.  I'd agree though we want applications to be independent (and this
gets to containerizing).

>  2. The build queue clearly shows what tasks are happening and about to
>  happen, along with time metrics, git changes and direct console output

I'll admit Jenkins has a much better out of the box experience here. 
Though I'm still very wary of exposing anything that's privileged enough
to affect the build process to the Internet.

The fact that you can only change Continuous via "git commit" which is
audited/tracked, and has its own robust authentication mechanisms I see
as a major plus.

> In a short discussion Colin's main consideration was security. I guess
> we'd better set anonymous users to read-only (and even hide some jobs if
> needed) and create accounts for the interested people (or use gnome's
> LDAP data if available).

Even better to run Jenkins as a separate uid with no write access to the
OSTree repository, etc, and ACLs to read-only.

However there's another important question here - do we require Jenkins
for the developer scenario?  If I want to hack locally on my laptop,
"ostbuild make -n build" with override git repos still works?