Open Stack

On Fri, Nov 27, 2020 at 02:11:21PM +0000, Tristan Cacqueray wrote:
> From what I understand, we can either use java and the polymer template
> system, or the javascript api to implement the zuul results table.

This was discussed today in the infra meeting @ [1]

There was a couple of broad conclusions.  There's no dispute that it
works, for now.  The maintenace of this in perpituity is the major
concern.

Some points:

There are already two Zuul plugins in the upstream repos

 zuul : https://gerrit.googlesource.com/plugins/zuul  --
  This is rather badly namespaced, and is focused on showing the
  status of Depends-On: changes a cyclic dependencies

zuul-status : https://gerrit.googlesource.com/plugins/zuul-status/ --
  This is also using a broad namespace, and appears to be related to
  showing the ongoing job status in the UI directly, but does not show
  final results.  An example I found at [2] from an old wikimedia
  thread

Upstream have shown to take some interest in these plugins when
undertaking upgrades to polymer, etc.  and thus integrating there is
seen as the best practice.  Unless we have a strong reason not to, we
would like to consume any plugins from upstream for this reason.

It would be in our best interest to work with these existing plugins
to clarify what they do more directly and come up with some better
namespacing to make it more obvious as potential number of plugins
grows.

The current proposed implementation does not look like any of the
upstream plugins.  Admittedly, [3] shows this is not a strong
eco-system; the documentation is mostly TODO and examples are thin.
Implementing this with Reason [4] adds one more significant hurdle; we
have no track record of maintaing this javascript dialect and it is
not used upstream in any way.  It also doesn't use the same build and
test frameworks; this may not be a blocker but again creates hurdles
by being different to upstream.  One more concrete comment is that I'm
pretty sure walking the shadow DOM to update things is [5] not quite
as intended and we should be using endpoints.

In trying to find the best place to start, I've pulled out bits of the
checks plugin, image-diff plugin and codeeditor plugin into the
simplest thing I could get to a tab with a table in it @ [6].  You can
see this for now @ [7].  I think we're going to get more potential
eyes using polymer components and making things look like the existing
plugins.  It's a matter of taste but I think the blank canvas of a
separate tab serves the purpose well.  I think with the Bazel build
bits, we can ultimately write an upstream Zuul job to build this for
us in gerrit's Zuul (corvus might know if that's right?)

Tristan -- maybe as step one, we could try integrating what you have
into that framework?  Maybe we rewrite the ReasonML ... but having it
something is step 1.  Overall I think this is the broad strokes of
what we would look at sending upstream.  If they think it's too
specific, Zuul tenant seems a logical home.

We would also like to expand the gate testing to better handle testing
plugins.  This will involve us automatically adding a repo, sample
change, and Zuul user comments during the gate test.  A logical
extension of this would be to take samples using a headless browser
for reporting as artifacts; held nodes can also be used for advanced
debugging.  This will give us better confidence as we keep our Gerrit
up-to-date.

I'd like to solict some feedback on the checks plugin/API, which Zuul
added support for with [8].  My understanding is that this has never
really consolidated upstream and is under redevelopment [9].  I don't
think there's much there for us at this point; even still seeing as we
are so Zuul centric we might be able to do things with a specific
plugin this API will never do.

-i


[1] http://eavesdrop.openstack.org/meetings/infra/2020/infra.2020-12-01-19.01.log.html#l-62
[2] https://imgur.com/a/uBk2oxQ
[3] https://gerrit-review.googlesource.com/Documentation/pg-plugin-dev.html
[4] https://reasonml.github.io/
[5] https://github.com/softwarefactory-project/zuul-results-gerrit-plugin/blob/master/src/ZuulResultsPlugin.re#L25
[6] https://github.com/ianw/gerrit-zuul-summary-status
[7] https://104.130.172.52/c/openstack/diskimage-builder/+/554002
[8] https://opendev.org/zuul/zuul/commit/e78e948284392477d385d493fc9ec194d544483f
[9] https://www.gerritcodereview.com/design-docs/ci-reboot.html