@Paladox I feel sorry this has taken sometime. Now that we have Gerrit 3.2 and I have entirely overhauled how we deploy plugins, I guess I can test the zuul-status plugin and look at deploying it on our instance. Or maybe it is not compatible with 3.2 but I guess I can easily verify that locally. I might give it a shot :]

Change 859127 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/software/gerrit@deploy/wmf/stable-3.5] Display Zuul status of jobs for a change in Gerrit

https://gerrit.wikimedia.org/r/859127

It is merely a proof of concept:

As a teaser I found a way to load the plugin against our own instance (using incognito mode to be sure and the Chromium extension Gerrit FE Dev Helper.

Loaded against https://gerrit.wikimedia.org/r/c/mediawiki/core/+/859146/4 :

It scraps the messages reported by Zuul.

The Checks API has support for polling so the work done on https://gerrit.wikimedia.org/r/859127 can be rebased to use the Check API as well.

Change 860863 had a related patch set uploaded (by Hashar; author: Hashar):

[integration/config@master] zuul: add pipelinename to autogenerated:ci tags

https://gerrit.wikimedia.org/r/860863

Change 860863 merged by jenkins-bot:

[integration/config@master] zuul: add pipelinename to autogenerated:ci tags

https://gerrit.wikimedia.org/r/860863

Mentioned in SAL (#wikimedia-releng) [2022-11-25T12:45:29Z] <hashar> Reloaded Zuul for I717ad1fe4ef7b151808b242cdf16f0268c58fbd7 "add pipelinename to autogenerated:ci tags" # T214068

Change 859083 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/software/gerrit@deploy/wmf/stable-3.5] Replace CI results table by Gerrit Check API

https://gerrit.wikimedia.org/r/859083

Change 860885 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/software/gerrit@deploy/wmf/stable-3.5] Document how to test a JavaScript Gerrit plugin

https://gerrit.wikimedia.org/r/860885

I have posted to wikitech-l how one can try out the plugin locally: https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/3ULF5NPVC4MSVABZBSXAMDODLZUKFXHS/ . That should provide a bit of feedback and bug reporting before deploying it live.

Change 860885 merged by jenkins-bot:

[operations/software/gerrit@deploy/wmf/stable-3.5] Document how to test a JavaScript Gerrit plugin

https://gerrit.wikimedia.org/r/860885

Change 859083 merged by jenkins-bot:

[operations/software/gerrit@deploy/wmf/stable-3.5] Replace CI results table by Gerrit Check API

https://gerrit.wikimedia.org/r/859083

Mentioned in SAL (#wikimedia-operations) [2022-12-13T11:52:04Z] <hashar@deploy1002> Started deploy [gerrit/gerrit@9ef1a16]: Replace CI result table by Checks API plugin - T214068

Mentioned in SAL (#wikimedia-operations) [2022-12-13T11:52:14Z] <hashar@deploy1002> Finished deploy [gerrit/gerrit@9ef1a16]: Replace CI result table by Checks API plugin - T214068 (duration: 00m 11s)

Mentioned in SAL (#wikimedia-operations) [2022-12-13T11:55:04Z] <hashar@deploy1002> Started deploy [gerrit/gerrit@9ef1a16]: Replace CI result table by Checks API plugin - T214068

Mentioned in SAL (#wikimedia-operations) [2022-12-13T11:55:13Z] <hashar@deploy1002> Finished deploy [gerrit/gerrit@9ef1a16]: Replace CI result table by Checks API plugin - T214068 (duration: 00m 09s)

I have deployed the Checks UI integration which is processing results posted as comments.

I might polish up the other plugin which injects Zuul live data below the commit message ( https://gerrit.wikimedia.org/r/c/operations/software/gerrit/+/859127/ ):

But most probably that code should be ported to the Checks UI. It has supports to inject in progress runs and I will have to dig into it.

Mentioned in SAL (#wikimedia-operations) [2022-12-14T08:25:53Z] <hashar@deploy1002> Started deploy [gerrit/gerrit@c0b0a70]: Add support for PipelineBot to the Checks API plugin - T214068

Mentioned in SAL (#wikimedia-operations) [2022-12-14T08:26:04Z] <hashar@deploy1002> Finished deploy [gerrit/gerrit@c0b0a70]: Add support for PipelineBot to the Checks API plugin - T214068 (duration: 00m 11s)

Mentioned in SAL (#wikimedia-operations) [2022-12-14T08:39:47Z] <hashar@deploy1002> Started deploy [gerrit/gerrit@c0b0a70]: Add support for PipelineBot to the Checks API plugin - T214068

Mentioned in SAL (#wikimedia-operations) [2022-12-14T08:39:56Z] <hashar@deploy1002> Finished deploy [gerrit/gerrit@c0b0a70]: Add support for PipelineBot to the Checks API plugin - T214068 (duration: 00m 09s)

Change 876238 had a related patch set uploaded (by Hashar; author: Hashar):

[integration/docroot@master] dev: Access-Control-Allow-Headers for json files

https://gerrit.wikimedia.org/r/876238

Change 876239 had a related patch set uploaded (by Hashar; author: Hashar):

[integration/docroot@master] zuul: add a sample status for a specific patchset

https://gerrit.wikimedia.org/r/876239

Change 876238 merged by jenkins-bot:

[integration/docroot@master] dev: Access-Control-Allow-Headers for json files

https://gerrit.wikimedia.org/r/876238

Change 900663 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/puppet@production] contint: allow CORS header for Zuul change status

https://gerrit.wikimedia.org/r/900663

(this one is slowly progressing here and there, I am revisiting the code when time allow)

Change 876239 abandoned by Hashar:

[integration/docroot@master] zuul: add a sample status for a specific patchset

Reason:

I will include it in operations/software/gerrit deploy branch instead I9545f3162d85aeac6f507eccdb8a105c2cddff24

https://gerrit.wikimedia.org/r/876239

Progress from last time, querying https://integration.wikimedia.org/zuul/status/change/123456,99:

A detailed view filtering on gate-and-submit:

I had to use some fancy ascii characters to represent the job progress since Gerrit only accepts a raw text.

It shows the pending jobs under Success while the status is undetermined. I don't think there is a Pending status, I went to add a tag or maybe I have missed something somewhere.

Change 900663 abandoned by Hashar:

[operations/puppet@production] contint: allow CORS header for Zuul change status

Reason:

Scott Basset provided details and gave a useful reference https://www.sans.org/blog/security-impact-of-http-caching-headers/ . Cache-Control is potentially scary.

The real issue is the Gerrit FE dev helper Chromium extension which is injecting: `Cache-Control: max-age=0, no-cache, no-store, must-revalidate`. Once deployed to Gerrit, users browsing the site would not have such header so there is no need to allow it ;)

https://gerrit.wikimedia.org/r/900663

Change 859127 merged by jenkins-bot:

[operations/software/gerrit@deploy/wmf/stable-3.5] Display Zuul status of jobs for a change in Gerrit

https://gerrit.wikimedia.org/r/859127

Very nice!

In T214068#8723722, @Krinkle wrote:

Very nice!

Thanks Timo for the TypeScript linting and your QUnit guidance!

I have posted an announce on wikitech-l: Zuul CI status now displayed on Gerrit changes.

This is great! Thank you! 🙇

Very cool, thank you!

One thing I noticed was this null on a change that I just pushed (i.e. CI had just started):

Also, when the test runs finish, they vanish instead of being replaced by the finished output:

In T214068#8723990, @Lucas_Werkmeister_WMDE wrote:

Very cool, thank you!

One thing I noticed was this null on a change that I just pushed (i.e. CI had just started):

That is supposed to be the name of the Zuul Pipeline (test, gate-and-submit etc).

Edit:

The name of the check in Gerrit UI is determinated by:

checkName: status.jobs[0].pipeline,

On the Zuul server side pipeline is not always set:

'pipeline': build.pipeline.name if build else None,

So until there is a build going on, the pipeline is not found.

Also, when the test runs finish, they vanish instead of being replaced by the finished output:

After reloading the page:

Definitely and I don't have a good solution for that. The issue is that once all jobs have completed, Zuul reports to Gerrit and the change is removed from the Zuul status. The code thus does not see anything running for the change ([]) and the tests vanishes. Given Zuul has reported to Gerrit, the other JavaScript plugin shows the reported results once the page is reloaded, I guess I can look at having the comments reloaded when the change has been processed by Zuul.

Thank you for the reports!

A similar issue has been reported:

Error while fetching results for wm-zuul-status: TypeError: status.jobs[0] is undefined

That one is easy, parent of a change are represented in Zuul even though they have nothing running in which case they are marked with live: false. Example:

[
  {
    "failing_reasons": [],
    "items_behind": [
      "902534,2"
    ],
    "jobs": [],
    "url": "https://gerrit.wikimedia.org/r/c/mediawiki/core/+/902533",
    "item_ahead": null,
    "enqueue_time": 1679655710156,
    "project": "mediawiki/core",
    "owner": {
      "username": "tstarling",
      "name": "Tim Starling",
      "email": "tstarling@wikimedia.org"
    },
    "live": false,
    "remaining_time": 0,
    "zuul_ref": "Za8c817b5d97a4322920d33fc9c1be3db",
    "active": true,
    "id": "902533,2"
  },
...
]

Even though that change had no jobs running, it appears because the child change https://gerrit.wikimedia.org/r/c/mediawiki/core/+/902534/ was being represented and the 902533 → 902534 dependency is represented in Zuul.

Non live changes should be filtered out.

Change 902705 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/software/gerrit@deploy/wmf/stable-3.5] wm-zuul-status: filter out non-live item

https://gerrit.wikimedia.org/r/902705

Change 902718 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/software/gerrit@deploy/wmf/stable-3.5] wm-zuul-status: fix items having no build

https://gerrit.wikimedia.org/r/902718

Change 902705 merged by jenkins-bot:

[operations/software/gerrit@deploy/wmf/stable-3.5] wm-zuul-status: filter out non-live item

https://gerrit.wikimedia.org/r/902705

I have deployed a fix for TypeError: status.jobs[0] is undefined showing when there is a dependent change. The same error will still show up when a change has been added and none of the jobs started yet, that is the pending change https://gerrit.wikimedia.org/r/c/operations/software/gerrit/+/902718

Change 902718 merged by jenkins-bot:

[operations/software/gerrit@deploy/wmf/stable-3.5] wm-zuul-status: fix items having no build

https://gerrit.wikimedia.org/r/902718

With this morning update, I think we will no more encounter TypeError: status.jobs[0] is undefined errors as well as null being shown when no jobs have started yet (that now displays Waiting for jobs instead).

There is one last thing I would like to polish up from T214068#8723990

Also, when the test runs finish, they vanish instead of being replaced by the finished output:

If the code noticed a change being in progress and it is no more shown by the Zuul status page, then Zuul should have reported on the Gerrit change. We thus need somehow to ask Gerrit to update the posted messages but I have no idea how to do it, I will ask upstream.

Change 905708 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/software/gerrit@deploy/wmf/stable-3.5] wm-zuul-status: change pending jobs SUCCESS > INFO

https://gerrit.wikimedia.org/r/905708

Change 905708 merged by jenkins-bot:

[operations/software/gerrit@deploy/wmf/stable-3.5] wm-zuul-status: change pending jobs SUCCESS > INFO

https://gerrit.wikimedia.org/r/905708

Mentioned in SAL (#wikimedia-operations) [2023-04-04T19:58:16Z] <hashar@deploy2002> Started deploy [gerrit/gerrit@dbaaa7a]: wm-zuul-status: change pending jobs SUCCESS > INFO | T214068

Mentioned in SAL (#wikimedia-operations) [2023-04-04T19:58:24Z] <hashar@deploy2002> Finished deploy [gerrit/gerrit@dbaaa7a]: wm-zuul-status: change pending jobs SUCCESS > INFO | T214068 (duration: 00m 07s)

When a new message is posted to a change, the Gerrit Web UI will shows a notification at the bottom stating something such as:

There are new messages on this change from jenkins-bot
Click here to reload the page

That comes from the Web UI polling every 5 minutes via a window.setTimeout() which fetches the change messages. The polling interval can be configured on the server side via change.updateDelay (default 5 minutes).

From the timeout call back in app/elements/change/gr-change-view/gr-change-view.ts it might be possible for our plugin to fire an event. The poller has:

this._cancelUpdateCheckTimer();
this.dispatchEvent(
  new CustomEvent<ShowAlertEventDetail>('show-alert', {
    detail: {
      message: toastMessage,
      // Persist this alert.
      dismissOnNavigation: true,
      showDismiss: true,
      action: 'Reload',
      callback: () => fireReload(this, true),      
    },
    composed: true,
    bubbles: true,
  })
);

fireReload comes from utils/event-util, no idea whether that is reachable from the plugin.

another example is when deleting a draft from app/elements/shared/gr-comment/gr-comment.ts which fires a show-alert upon deletion and I guess ends up showing the alert (hence the event name):

return this.restApiService
  .deleteDiffDraft(changeNum, patchNum, {id: draftID})
  .then(result => {
    if (result.ok) {
      fire(this, 'show-alert', {
        message: 'Draft Discarded',
        action: 'Undo',
        callback: () =>
          this.commentsService.restoreDraft(changeNum, patchNum, draftID),
      });
    }
    return result;
  });

I gave it a try again this week-end and could not find a way for a plugin to trigger an alert with a callback to reload the page. I guess I should upstream for some guidance which I have did on Gerrit discord channel #gerrit-fe

hi, I could use some guidance, I have a Check API plugin displaying ongoing progress in our CI system. At the end of the builds, they vanish from the queried API and there is thus no checks shown anymore but they did get reported on the Gerrit change which we use to store the state of results (yes I know it is terrible).

When there are no more builds found in CI, I would like to show an alert notification proposing the user to reload a change, similar to the alert showing when a new patchset got send.

I see the gr-change-view fires a show-alert event with a Reload action and fireReload callback. I thought I could potentially reuse that but could not find a way to do it https://phabricator.wikimedia.org/T214068#8758617
Should I maybe copy paste the logic?
Would emitting a show-alert event from my plugin be caught by whatever is handling it? 😉

Ben Rohlfs answer:

The error manager listens on document for show-alert events. So yes, you can fire such an event from a plugin and it would be picked up: https://cs.opensource.google/gerrit/gerrit/gerrit/+/master:polygerrit-ui/app/elements/core/gr-error-manager/gr-error-manager.ts;l=128;drc=f3dc4cf4e21925adf47da42aade62e6fa970f477

polygerrit-ui/app/elements/core/gr-error-manager/gr-error-manager.ts

document.addEventListener('show-alert', this.handleShowAlert);

Can you try document.dispatchEvent(new Event('reload')); instead of fireReload()?

This should be picked up here and thus do a reload as you desire: https://cs.opensource.google/gerrit/gerrit/gerrit/+/master:polygerrit-ui/app/models/views/change.ts;l=338;drc=0d12586344164500a62ec72a44ed3e84464cc12c

polygerrit-ui/app/models/views/change.ts

document.addEventListener('reload', this.reload);

Change 920708 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/software/gerrit@deploy/wmf/stable-3.5] wm-zuul-status: offer to reload on CI completion

https://gerrit.wikimedia.org/r/920708

I had some trouble with triggering the reload cause it is not attached to document but to a gr-change-view element which is deeper in the DOM. Eventually I got something with:

document.querySelector('gr-app')
              .shadowRoot.querySelector('gr-app-element')
              .shadowRoot.querySelector('gr-change-view')
              .dispatchEvent(new Event('reload'))

One can copy paste that in the browser console of a Gerrit change and it does reload the page. That causes messages that got posted meanwhile to be shown which then get processed and displayed under the Check table (and as a bubble under the commit message).

The WIP patch I have send lacks the logic to detect when to offer the user to reload.

Change 920708 merged by jenkins-bot:

[operations/software/gerrit@deploy/wmf/stable-3.5] wm-zuul-status: offer to reload on CI completion

https://gerrit.wikimedia.org/r/920708

Mentioned in SAL (#wikimedia-operations) [2023-05-23T07:44:02Z] <hashar@deploy1002> Started deploy [gerrit/gerrit@e815301]: wm-zuul-status: offer to reload on CI completion | T214068

Mentioned in SAL (#wikimedia-operations) [2023-05-23T07:44:09Z] <hashar@deploy1002> Finished deploy [gerrit/gerrit@e815301]: wm-zuul-status: offer to reload on CI completion | T214068 (duration: 00m 07s)

Mentioned in SAL (#wikimedia-operations) [2023-05-23T07:51:39Z] <hashar@deploy1002> Started deploy [gerrit/gerrit@d151775]: wm-zuul-status: offer to reload on CI completion | T214068

Mentioned in SAL (#wikimedia-operations) [2023-05-23T07:51:46Z] <hashar@deploy1002> Finished deploy [gerrit/gerrit@d151775]: wm-zuul-status: offer to reload on CI completion | T214068 (duration: 00m 07s)

I had to deploy a second time since I forgot to git rebase to bring in the change!

In T214068#8723990, @Lucas_Werkmeister_WMDE wrote:

...
Also, when the test runs finish, they vanish instead of being replaced by the finished output:

After reloading the page:

I have implemented it via Gerrit #920708: offer to reload on CI completion and deployed it. It is off by one, the popup only shows up after a second fetch though cause the logic is called before the fetch rather than after, but it does work!dssss

Change 922472 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/software/gerrit@deploy/wmf/stable-3.5] wm-zuul-status: show reload immediately

https://gerrit.wikimedia.org/r/922472

Change 922472 merged by jenkins-bot:

[operations/software/gerrit@deploy/wmf/stable-3.5] wm-zuul-status: show reload immediately

https://gerrit.wikimedia.org/r/922472

Mentioned in SAL (#wikimedia-operations) [2023-05-23T08:44:09Z] <hashar@deploy1002> Started deploy [gerrit/gerrit@69bc27c]: wm-zuul-status: show reload immediately | T214068

Mentioned in SAL (#wikimedia-operations) [2023-05-23T08:44:15Z] <hashar@deploy1002> Finished deploy [gerrit/gerrit@69bc27c]: wm-zuul-status: show reload immediately | T214068 (duration: 00m 07s)