[openstack-dev] [all] 3rd Party CI vs. Gerrit

James E. Blair corvus at inaugust.com
Wed Aug 13 20:02:15 UTC 2014

Dan Smith <dms at danplanet.com> writes:

>> You may have noticed that this has merged, along with a further change
>> that shows the latest results in a table format.  (You may need to
>> force-reload in your browser to see the change.)
> Friggin. Awesome.
>> Thanks again to Radoslav Gerganov for writing the original change.
> Thanks to all involved, as this is a major improvement for everyone!
> One thing that we discussed at the nova meetup was having a space for
> each CI we *expect* to vote. I haven't looked at the implementation
> here, but I assume it just parses the comments to generate the table.
> How hard would it be to make the table show all the CI systems we expect
> so that it's very obvious that one has gone MIA (as they often do)
> before we merge a patch? I think we struggle right now with merging
> things that a CI system would have NAKed, but only because we didn't
> notice that it hadn't voted.

I think my preferred method of doing this would be to drive all
third-party CI systems from OpenStack's Zuul.  We are not far from being
able to do that technically, though it's not clear to me that there is
the will for third party CI systems to do that.  However, if we really
are expecting them to report back and are willing to hold up merging a
change because of it, then we really should consider that.

As we look into using a Gerrit plugin for test results, we could see
about adding that as a feature.

Something that we could technically do immediately would be to add
third-party CI systems as reviewers to changes when they are uploaded.
Then they would show up in the list of reviewers at the top of the
change.  This would require maintaining a list of which systems were
expected to vote on which repositories.  Rather than keeping that in
git, we could use group membership for it (and implement something we
have talked about off-and-on, which is using Gerrit group membership to
grant voting privileges to each individual repository).  That would also
allow projects to self-manage both who is permitted to vote on their
repos and who is expected to vote.


More information about the OpenStack-dev mailing list