Page MenuHomePhabricator

Create a new gerrit bot for Patch Demo
Open, Needs TriagePublic

Description

Patch demo has a Phabricator bot (@PatchDemoBot) that announces new wikis to the corresponding tasks, but it has also been requested to post on the Gerrit patch too (https://github.com/MatmaRex/patchdemo/issues/285). Can a new bot be created on Gerrit called PatchDemoBot?

Event Timeline

There is no robot per see in Gerrit, the only exception is the its-phabricator which adds comments to Phabricator whenever a change refers to a task (via Bug: T#### in the commit headers).

For Patchdemo there are two ways to expose a site has been created for a given change:

Patchdemo sending a review

The system can be made to send a comment on the change preferably using REST API ( https://gerrit.wikimedia.org/r/Documentation/rest-api-changes.html#set-review ). That will requires the creation of a user account for Gerrit and mark it as a bot account (I have documented that just now at https://wikitech.wikimedia.org/wiki/Gerrit/Bot_account ). Then whenever a VM is created, the process can send a review back to users who will get an email notification. A disadvantage is the comments will be left in the git repository forever even after the VM got deleted/recycled. That is what Zuul CI (reporting as <code>jenkins-bot</code> is using.

The reported messages can be scrapped and integrated in the Gerrit Check UI (see below).

Check UI integration

An alternative is to have the patch demo service to expose a small web service that the Gerrit web ui can query. Whenever someone browse a change, the Gerrit frontend code would do a http request to patchdemo for the currently browsed change/patchset and the service would send back some json payload as to whether a wiki is available and potentially with some over details. That can then be shown below the commit message as an informational message and in the detailed view with some extra links. An example of the integration I have made for Zuul CI:

Zuul 2.5 report in Gerrit Checks UI (865×1 px, 145 KB)

This requires patchdemo to keep a state (which I guess it does in order to reclaim VM after a certain time) and add some web service to expose the state as json. A disadvantage is people do not receive an email notification since no comment is added to the change, I guess patchdemo can handle that. The Check UI can integrate a pending verification to which we can add a button which would do a request to patch demo to create the VM and provided the service exposes the step of the VM creation, the progress can exposed in the UI as well.

The Check UI integration is the preferred way since messages are not stored in the Gerrit database. The only drawback is there is no UI / email notification, but the emailing part can be handled by the bot while the UI part can be handled by the Checks UI.

I note patchdemo already has an API, for example https://patchdemo.wmflabs.org/api.php?patch=889642,73 yields:

[
  {
    "commit": "efebda9dae323e5c79ac296597a864dff28b2788",
    "parents": [
      {
        "commit": "968f282ebcbe76cfe0b67a95b1b2e808ec0e3722",
        "subject": "Personalized praise: Add notifications"
      }
    ],
    "author": {
      "name": "Martin Urbanec",
      "email": "martin.urbanec@wikimedia.cz",
      "date": "2023-03-02 14:20:33.000000000",
      "tz": 60
    },
    "committer": {
      "name": "Urbanecm",
      "email": "martin.urbanec@wikimedia.cz",
      "date": "2023-03-20 09:23:33.000000000",
      "tz": 0
    },
    "subject": "WIP: Frontend for Personalized praise module",
    "message": "WIP: Frontend for Personalized praise module\n\nCurrent implementation of the \"Send appreciation\"\nbutton requires T269310 to be resolved (see Depends-On).\n\nToDo:\n\n* Styling doesn't match the Figma specs yet\n* Add the (i) icon pop\n* Finish settings module\n\nTo consider:\n* Two sources of truth for praising message content:\n  Currently, praising message content is stored in\n  BOTH the preferences and the on-wiki page. The preferences\n  version is used to populate the Settings dialog, the on-wiki\n  one for the actual preloading. Ideally, the store will get\n  the praising message from the on-wiki page to populate settings.\n\nBug: T322443\nBug: T322446\nDepends-On: I4ee024cc4760542790319f302f42b1b2389ac897\nChange-Id: I0ba03ce7b3dffcfd2c17e58753f026e057803492\n",
    "r": 889642,
    "p": 73,
    "linkedTasks": [
      "322443",
      "322446"
    ]
  }
]

Had the API got the URL to the spawned Wiki we could show it up in the Gerrit Checks API. We could then potentially add actions to Create Delete VM.

I note patchdemo already has an API, for example https://patchdemo.wmflabs.org/api.php?patch=889642,73 yields:

[
  {
    "commit": "efebda9dae323e5c79ac296597a864dff28b2788",
    "parents": [
      {
        "commit": "968f282ebcbe76cfe0b67a95b1b2e808ec0e3722",
        "subject": "Personalized praise: Add notifications"
      }
    ],
    "author": {
      "name": "Martin Urbanec",
      "email": "martin.urbanec@wikimedia.cz",
      "date": "2023-03-02 14:20:33.000000000",
      "tz": 60
    },
    "committer": {
      "name": "Urbanecm",
      "email": "martin.urbanec@wikimedia.cz",
      "date": "2023-03-20 09:23:33.000000000",
      "tz": 0
    },
    "subject": "WIP: Frontend for Personalized praise module",
    "message": "WIP: Frontend for Personalized praise module\n\nCurrent implementation of the \"Send appreciation\"\nbutton requires T269310 to be resolved (see Depends-On).\n\nToDo:\n\n* Styling doesn't match the Figma specs yet\n* Add the (i) icon pop\n* Finish settings module\n\nTo consider:\n* Two sources of truth for praising message content:\n  Currently, praising message content is stored in\n  BOTH the preferences and the on-wiki page. The preferences\n  version is used to populate the Settings dialog, the on-wiki\n  one for the actual preloading. Ideally, the store will get\n  the praising message from the on-wiki page to populate settings.\n\nBug: T322443\nBug: T322446\nDepends-On: I4ee024cc4760542790319f302f42b1b2389ac897\nChange-Id: I0ba03ce7b3dffcfd2c17e58753f026e057803492\n",
    "r": 889642,
    "p": 73,
    "linkedTasks": [
      "322443",
      "322446"
    ]
  }
]

Had the API got the URL to the spawned Wiki we could show it up in the Gerrit Checks API. We could then potentially add actions to Create Delete VM.

The API is for the autocomplete when creating a wiki, but it could be modified to find wikis based on a patchset.

Either approach sounds good, although I wouldn't know how to implement the Check UI integration. If you know what to do there's a patch for the API up on GitHub.

I don't mind doing it, is merely about doing a fetch() processing the received data and return the CheckResults data structure described at https://gerrit.googlesource.com/gerrit/+/stable-3.5/polygerrit-ui/app/api/checks.ts (for Gerrit 3.5).

The one I have did crawling the comments is at https://gerrit.wikimedia.org/g/operations/software/gerrit/+/refs/heads/deploy/wmf/stable-3.5/plugins/wm-checks-api.js which is overcomplicated for sure. One that does a fetch then transform to the structure expected by Gerrit should not be too hard ;)

The API is now live, example: https://patchdemo.wmflabs.org/api.php?action=findwikis&change=822099

As described on https://github.com/MatmaRex/patchdemo/pull/537#issuecomment-1476446486, we are looking for an output something like:

RunSummary
Patchdemo↗️ 0483bb0894 PS3, 4 days ago
Patchdemo↗️ 2ca64449dd PS4, 2 hours ago
Patchdemo↗️ 449dd2ca64 PS4, 10 minutes ago

The patchset number can be found by iterating over the patches array in the result row and finding the entry with the same change number.