Proposal: instance-wide bugbot implementation using gitlab-triage

Filing this issue to gather interest before I put the effort into making this site-wide.

Summary

The intention is to create a new @bugbot user that applies a project's individual gitlab-triage policies file in response to a bugbot::* label added to a webhook or merge request. Project can sign with the equivalent to the damspam spam handling signup.

This allows projects/maintainers that have often repeated processes in issues/MRs to standardise on templates those processes. The primary example I can see is the wayland project which gets a lot of issues filed that aren't a wayland protocol bug - this could be addressed with a simple rule (example below) and reduce the maintainer effort to just applying a label.

Details

gitlab-triage is a tool by GitLab that uses a YAML file to perform actions on issues, merge requests, etc. An example rule would look like this:

host_url: https://gitlab.freedesktop.org
resource_rules:
  issues:
    rules:
      - name: Bugbot kernel label
        conditions:
          labels:  # project-specific bugbot labels to trigger a rule
            - bugbot::kernel
        actions:
          comment: |
            This issue has been labeled as a kernel issue - it cannot be fixed in libinput, it
            needs to be fixed in the kernel. I'm going to close this issue but do feel free
            to keep discussing things here.
          labels:  # labels to be added
            - kernel
            - not our bug
          remove_labels:  # labels to remove
            - bugbot::kernel
          status: close  # close the issue

This policy file would be part of the project (libinput in this case), and should be fairly self-explanatory. this issue is an test of this applied, albeit with my user token. The full documentation for the YAML file and possible actions and conditions is here.

The process for a project signed up to bugbot would be:

1. issue or MR is assigned a bugbot::foo label
2. the webhook notifies the bugbot hookiedookie service which checks for a new label starting with bugbot::
3. the hookiedookie service fetches the .triage-policies from the project's main or master branch
4. the hookiedookie service (after 30s) runs gitlab-triage --token $BUGBOT_TOKEN --source-id namespace/project --resource-reference #1234 which will apply any project-specific policies to the given issue (or MR). The delay allows a maintainer to remove an erroneously applied label before bot takes effect.

Notably:

• which bugbot::foo labels exist is defined by the individual project
• what happens in response to a bugbot:: label is defined by the individual project's policy file
• the bugbot:: label is intentionally scoped to serve as command to bugbot only, this is a simple filter so the hookiedookie service doesn't have to worry about project-specific labels and there cannot be a clash with normal project labels.
• users seeing a bugbot:: label applied followed by an action by the @bugbot users should be immediately aware that this was an automated action
• actions are limited to whatever gitlab-triage supports which is basically "things you could do in the web UI" - there are currently no plans to run custom scripts in response to those hooks.

Note that gitlab-triage can be run as part of a scheduled pipeline in each individual project with custom rules. Running in response to a webhook is nicer IMO and somewhat standardises the process across projects.

cc @alanc, @benno, @bentiss, @daniels, @emersion, @ofourdan, @wtay please add others who do a lot of bug work and may want/need this.

Any interest in this?