Dan Smith 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.)
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.