Re: Jenkins-based Continuous

["Jasper St. Pierre" <jstpierre mecheye net>]

On Mon, Oct 20, 2014 at 12:49 PM, Vadim Rutkovsky <vrutkovs redhat com> wrote:

Hi,

On Mon, Oct 20, 2014, at 07:19 PM, Colin Walters wrote:
> I don't understand that - with Continuous I was intentionally trying to
> get away from the "package" mindset of lots of individual little
> fiefdoms.

I guess a better way would be assigning each component a group - SDK / Application.
Any build error in SDK group should block other SDK packages,
Apps should be built independently on any latest SDK.
If I'm not mistaken Alex Larsson is working on similar things, right?

GNOME Continuous is for testing GNOME. If GNOME is failing, then we break the build until GNOME is fixed. If I break gnome-shell, I want to know about it, so I can fix it. And this stems from build failures to runtime failures: there's been a few times where glib has changed and caused mutter or epiphany to break, and we only caught it because of Continuous.

I see this as a big advantage over the package-based model. I want to keep this.

 

>> 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?

Not at the moment, but its possible. Currently Jenkins had three queues for tasks:
resolve, build and test tasks, but all of them were executed on one machine. However,
we could've used several build hosts for those, but that would require a shared FS or
some kind of sync between the nodes.

>Though I'm still very wary of exposing anything that's privileged enough
>to affect the build process to the Internet.

I guess Ubuntu guys have their Jenkins instance open [1], never heard they had any
problem with security.

The safest option is to rewrite build.gnome.org to display info using Jenkins API.

>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.

Build history (including build trigger and user) are also tracked in Jenkins - not in git repo,
however. So do the configuration changes with a plugin - afaik it is possible to require a
description for any change.

I don't like this. The only input to the system should be the gnome-continuous git repo, not some weird admin poking a big red button or changing configuration on a web UI. The Jenkins UI is a poor fit for this, I feel. There's also others like Mozilla's buildbot which you might want to take a look at.

 

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

Yes, my test instance is doing that - a build 'node' is started via ssh'ing to localhost using
different user with key authentication.

>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?

Definitely. Jenkins might also work as 'scratch build service' - to try out the patch / different branch.

I think this is worth investigating. We've talked about adding this into Continuous by having some component have a "scratch/foo" branch, and Continuous would notice and build and give us smoketest / installed-test results. I still think we should interact with it with our existing tools like git and not a new web UI.

 

[1] https://jenkins.qa.ubuntu.com/

--
Thanks,
  Vadim

_______________________________________________
gnome-continuous-list mailing list
gnome-continuous-list gnome org
https://mail.gnome.org/mailman/listinfo/gnome-continuous-list

--
  Jasper