Re: Jenkins-based Continuous

[Vadim Rutkovsky <vrutkovs redhat com>]

Hi,

On Thu, Oct 23, 2014 at 2:20 AM, Jasper St. Pierre 
<jstpierre mecheye net> wrote:
> 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.

Indeed, anything critical should go in "SDK" group. Meanwhile 
gnome-calculator breaks shouldn't stop the whole process and hide other 
issues.

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

We can always disable it. However making a new commit for each ABI 
break seems pointless to me - we should be able to detect those 
automatically.

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

Creating two commits (switch branch and revert back to master) is an 
overkill imho. Those results would also skew test result stats in 
current implementation. In Jenkins we can create a generic temp job 
with "component" and "branch" params to test scratch changes and give 
them lesser priority - the results will not be a part of global stats 
and ostree can easily revert these changes.

Thanks,
 Vadim