Open Stack

"Clark Boylan" <cboylan at sapwetik.org> writes:

> How does triggering work with the checks api? I seem to recall reading
> the original design spec for the feature and that CI systems would
> Poll Gerrit for changes that apply to their checks giving them a list
> of items to run? Then as a future improvement there was talk of having
> a callback system similar to Github's app system?

Yes, that's essentially correct.  That's actually why implementing
support for this now in Zuul helps us with the effort to run jobs
against upstream Gerrit, since our *only* option there is to poll, due
to the lack of stream-events support.

The polling operation is designed to be very efficient -- each time you
get back a list of changes which are configured to run the checker, but
where it hasn't reported start yet.

A future enhancement is an event (which would show up in stream-events,
so perhaps useful in most installations, but still not upstream gerrit)
and also a webhook (which would work in upstream gerrit I think).  The
event would merely indicate that a poll should be performed.  That's
good enough, and would allow us to achieve the near-instantaneous
response we have now.

(Having said that, we may be able to have a fairly frequent poll
interval on upstream gerrit without problems.)

-Jim