[OpenStack-Infra] Zuul V3: Behavior of change related requirements on push like events

James E. Blair corvus at inaugust.com
Tue May 30 20:45:38 UTC 2017


Jeremy Stanley <fungi at yuggoth.org> writes:

> On 2017-05-30 12:53:15 -0700 (-0700), Jesse Keating wrote:
> [...]
>> Github labels: This is like approvals/reviews.
> [...]
>
> Perhaps an interesting aside, Gerrit uses the same term (labels) for
> how we're doing approvals and review voting.

Yeah, or at least, related.  I think in Gerrit a "label" is a review
category (eg, "Verified", "Code Review") and an "approval" is a value
given by a user to a change in one of those categories (eg, "Verified:
+1", or "Code Review -2" would be an interestingly named "approval").

Of course, that's new[1]; they used to be called "categories" rather
than "labels".

>> Personally, my opinions are that to avoid confusion, change type
>> requirements should always fail on push type events. This means
>> open, current-patchset, approvals, reviews, labels, and maybe
>> status requirements would all fail to match a pipeline for a push
>> type event. It's the least ambiguous, and promotes the practice of
>> creating a separate pipeline for push like events from change like
>> events. I welcome other opinions!
>
> This seems like a reasonable conclusion to me.

Agreed -- we haven't run into this condition because our pipelines are
naturally segregated into change or ref related workflows.  I think
that's probably going to be the case for most folks, so codifying this
seems reasonable.  However, I could simply be failing to imagine a
pipeline that works with both.

-Jim

[1] As of six years ago.



More information about the OpenStack-Infra mailing list