Open Stack

On Wed, Dec 02, 2020 at 22:14 Ian Wienand wrote:
> 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
>

Note that my proposal goal is just to restore the missing table from
the new review.opendev.org user interface. I agree that it would be
better to follow how upstream does plugins.

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

This is looking great, thank you for looking into that.
I guess we can directly re-use the showResult function in-place of
the gr-zuul-summary-status-view_html.js content.

If using polymer template is required, then we can still re-use the 
the `CI.fromMessages` function exported by the re-gerrit library
to count the rechecks and extract build results from the message array.

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

It seems like the checks API enables a similar user interface where the
CI build details are integrated in the tablist along with a chip-view
under the commit message. It's unclear what are the requirements but
that looks like a good long term solution since we wouldn't need a
custom plugin for Zuul.

-Tristan

>
> [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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 515 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201202/a39b6f91/attachment-0001.sig>