On 30/11/15 12:51, Ruby Loo wrote:
On 30 November 2015 at 10:19, Derek Higgins <der...@redhat.com
<mailto:der...@redhat.com>> wrote:
Hi All,
A few months tripleo switch from its devtest based CI to one
that was based on instack. Before doing this we anticipated
disruption in the ci jobs and removed them from non tripleo projects.
We'd like to investigate adding it back to heat and ironic as
these are the two projects where we find our ci provides the most
value. But we can only do this if the results from the job are
treated as voting.
What does this mean? That the tripleo job could vote and do a -1 and
block ironic's gate?
In the past most of the non tripleo projects tended to ignore
the results from the tripleo job as it wasn't unusual for the job to
broken for days at a time. The thing is, ignoring the results of the
job is the reason (the majority of the time) it was broken in the
first place.
To decrease the number of breakages we are now no longer
running master code for everything (for the non tripleo projects we
bump the versions we use periodically if they are working). I
believe with this model the CI jobs we run have become a lot more
reliable, there are still breakages but far less frequently.
What I proposing is we add at least one of our tripleo jobs back to
both heat and ironic (and other projects associated with them e.g.
clients, ironicinspector etc..), tripleo will switch to running
latest master of those repositories and the cores approving on those
projects should wait for a passing CI jobs before hitting approve.
So how do people feel about doing this? can we give it a go? A
couple of people have already expressed an interest in doing this
but I'd like to make sure were all in agreement before switching it on.
This seems to indicate that the tripleo jobs are non-voting, or at least
won't block the gate -- so I'm fine with adding tripleo jobs to ironic.
But if you want cores to wait/make sure they pass, then shouldn't they
be voting? (Guess I'm a bit confused.)
+1
I don't think it hurts to turn it on, but tbh I'm uncomfortable with the
mental overhead of a non-voting job that I have to manually treat as a
voting job. If it's stable enough to make it a voting job, I'd prefer we
just make it voting. And if it's not then I'd like to see it be made
stable enough to be a voting job and then make it voting.
- ZB
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
