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