Open Stack

On 2016-08-04 01:27:23 +0100 (+0100), Kiall Mac Innes wrote:
> Without wanting to diverge too much from the topic at hand, I believe this
> is why those of us who only occasionally want to look at post job output
> usually just give up! Keeping this in your head for the once every few
> months it's needed is hard ;)
> 
> A change being merged is always (AFAIK) part and parcel with a review
> being closed, so - why not publish to /post/<review-number> (with some
> level of dir sharding)?

We've discussed this in the past. It's possible if we switch to
using Gerrit's change-merged events then there could be sufficient
context to run jobs on changes once they merge, as compared to the
raw Git SHAs ref-updated events currently supply for the post
pipeline. Though is that what you really want: coverage of the
change itself rather than coverage of the repository's state at the
point where that change merged?

My guess is that you're expecting some sort of additional magic to
figure out the merge commit associated with the change that merged
if there is one and then have jobs run on that, or else run jobs on
the change in the situation where no merge commit was needed. I
think this would get considerably more complicated, but I'll defer
to someone with deeper knowledge of Zuul's internals on the actual
complexity.
-- 
Jeremy Stanley