Bugzilla:GitHub Integration

Feature wanted: lots of integration with GitHub

Ideas:

• Pull Requests (PRs) can already be added to bugs as an attachment. But it's just a link with no details. Improvements could include:
  • Show the status of the PR from GitHub on the attachment table in Bugzilla
    • either use the API to fetch it and cache it for a bit, or store it somewhere and use a webhook from GitHub to update it when it changes. Or store it from the webhook and have a refresh button that'll use the API in case a webhook got missed (refresh might be an admin-only function, wouldn't want people using it too often).
  • Show the review status from the PR in Bugzilla (who it's assigned to, if it's been approved, etc)
  • Automatically add a PR to a Bugzilla bug if the bug number is mentioned on the PR (use webhook from GitHub)
• Automatically add a comment to a bug when a PR attached to it is merged or closed (use webhook)

Can implement these in phases, first up is the core infrastructure to make it happen:

Phase 1: Two way communication channel with GitHub

• Implement it as an extension, disabled by default. Use harmony routing infrastructure so it can be registered as a top level URL subdirectory. ( /webhooks/github/{generated key} )
• Configuration option to put in an API key to use to send information to GitHub
  • GitHub documentation: https://docs.github.com/en/rest
  • Perform minimum checks to make sure the API key works and can successfully get a non-destructive response from GitHub (grab a list of permissions the key has or something)
  • Provide a hook function for use by this or other extensions which can be called to send a request to GitHub and return the response.
• Endpoint to receive incoming web hooks from GitHub
  • GitHub documentation: https://docs.github.com/en/webhooks
  • Should be able to receive the webhooks and convert them into a perl object.
  • Minimal logging of the received hook.
  • Debug option available to log full hook contents, to assist developers when working on handling new hook types.
    • Perhaps in the database so individual hooks can be retrieved easily and parsed by a viewer for easy reading. Should require admin access to view, since some hooks do contain private data.
    • Should have a time limit where old ones go away after that period of time.
  • Call an internal extension hook with the object so this or another extension can grab the hook to deal with the contents of it. Perhaps classify it by the type of webhook and have specific extension hooks for each type.