Gerrit

Looking forward to it :-)

The benefits i see with using zuul is as the following:

* The UI makes it very easy to find builds. You can find you build easily without going through builds and checking if its your's.

* Zuul could have support for checkers be added.

* There's a plugin that integrates zuul into gerrit's ui (zuul-status). It supports both zuul v3 and zuul v2.

* You can inject env as wikimedia do with https://github.com/wikimedia/integration-config/blob/master/zuul/parameter_functions.py

* Plugins will be able to be tested as soon as patchsets are updated, or created just like gerrit core.

* Compared to v2, v3 makes it easier for projects to take control of how there repo is tested using the zuul config file in the repo.

Because jenkins will have to be dropped, we would have to create a new job that deploys artefacts to a separate host for users to download.

Also it uses Nodepool, so images will need to be built for nodepool. (I'm not sure if you can create a plugin so that nodepool is not required and that you can just use docker).

(I've only experenced zuul at wikimedia and only version 2 with jenkins).

Thanks a lot for adding these details!!

I think the first thing we need to do is make some changes to Zuul to support interacting with a Gerrit which does not have stream-events available.  Given that we need a polling-based system anyway, it makes sense to me to go straight to using the checks API (even though we will eventually want sub-checks for fine-grained reporting).  Once Zuul supports that, we can have OpenDev's Zuul start running builds of Gerrit (and also the checks plugin, since we're hoping to be able to test interaction there).  Performing this kind of third-party/cross-project testing is within the remit of our system, so that should be fine.  That will let us demonstrate a working Zuul system with upstream Gerrit.  We can evaluate that and then start working to set up a Zuul system using the Gerrit community's test resources if we want to proceed.

I think the steps are:

1) Add basic support for the checks API to Zuul
2) Create a service account on gerrit-review.googlesource.com for OpenDev's Zuul
3) Configure a checker on gerrit-review.googlesource.com for OpenDev's Zuul
4) Have OpenDev's Zuul start running Gerrit builds on changes to Gerrit
5) Gap analysis
6) Set up a Zuul using Gerrit project resources
7) Reduce the use of OpenDev's Zuul to cross-project testing (e.g. checks plugin)

Also, I will start working on a design doc for sub-checks, and hopefully work on that will progress in parallel.  Whenever that is ready, we can fold that in and the Zuul experience in Gerrit will be much improved.

If that looks like a good plan, I will start on #1 soon, and perhaps Edwin can help me with items #2 and #3?

> Given that we need a polling-based system anyway, it makes sense to me to go straight to using the checks API [...]

Good idea to use checks API, however, currently it still doesn't support optimized queries for changes pending for checks with scheme prefix. See my TODO list from the Gerrit Hackathon from May this year: [1]:

* Ability to query for a pending check using scheme-prefix, e.g., "scheme:"

> [...] (even though we will eventually want sub-checks for fine-grained reporting).

I do not understand what do you mean by that.

> 3) Configure a checker on gerrit-review.googlesource.com for OpenDev's Zuul

I configured the checks for GerritGorge CI during the hackathon in May this year, see: [2], and it should be straight forward to do the same  for OpenDev's Zuul CI. I have the needed ACLs and may be able to help with that.

[1] https://groups.google.com/d/msg/repo-discuss/rHIjzIlPzqY/zAGOaG6MAwAJ
[2] https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/224327/34/jenkins/checker_definitions.txt

Thanks for the additional info David!

>> [...] (even though we will eventually want sub-checks for fine-grained reporting).
>
> I do not understand what do you mean by that.

Sorry that wasn't clear.  We would like to have each job that Zuul runs made visible in Gerrit, but Zuul doesn't just run a fixed set of jobs; it dynamically evaluates what to run based on the content of the change (in fact, a change can propose its own new job that then runs on that very change).  Edwin and Alice suggested that the best way to acomodate this would be to implement sub-checks support, so that Zuul is a checker, and each job that it runs is a sub-check.  The next item on my TODO list is to write up a design document describing this use case and a proposed implementation, so hopefully that will make it more clear (if this short explanation doesn't).

None of that impacts this issue though -- we can have Zuul continue to report individual job results as review messages for now.  I just mentioned it mostly to make it clear it's not a blocker for this.

Indeed, using zuul to test gerrit itself would help the entire community by improving the integration. Users do want to easily be able to see live CI status directly on gerrit, maybe even be able to retry jobs from the UI. This more likely to happen if we start testing them together.

I have a patch series up for Zuul for initial support of the checks API at: https://review.opendev.org/#/q/status:open+topic:gerrit-checks

Next step is to finish ensuring we have support for cloning/fetching over HTTP since g-r.gs.com doesn't have ssh access.

Zuul CI is up and running on gerrit-review.

Awesome! Thanks everyone!!

[Monorail components: CI]

[Monorail components: -Build>CI]

[Empty comment from Monorail migration]

Edits were made to reflect the following in Monorail: auto-CCs.