Feedback on Integrations with existing bots at the Guardian


We’ve got a few different GitHub bots here at the Guardain - here’s a bit of a brain dump of how well supported they would be if they were switched to Integrations:

Prout -

Needs to be able to write labels and comments on PRs (“issues” permission), and read the contents of repos (“content” permission). I think all Prout’s needs are catered for by the Integrations support. An as additional change Prout could shift Project cards (eg pulling the PR into a ‘Seen in Prod’ column).

gu:who -

This bot helps with enforcing that all users in your GitHub org satisfy these 3 requirements:

  • 2FA (the introduction of articles/requiring-two-factor-authentication-in-your-organization/ means that this feature is almost useless, except we don’t want our bot accounts to use 2FA. Perhaps once all our bot accounts are converted to integrations this feature could be killed)
  • The user’s name is populated - I’m probably going to drop this as a requirement anyway, instead just encouraging the user to consider doing it - internet harassment means it’s wrong to /require/ ‘true’ names for public GitHub profiles.
  • There’s a record kept of who’s responsible for the user being in the Org (currently done with users.txt). GitHub’s organisation audit log is good, but only 3 months long, not enough to help with identifying who is responsible for a user, so that’s still a function that gu:who can help with.

However, the remove-user-from-organisation endpoint isn’t available, so gu:who can not do it’s job as an enforcer.


This caters to the Guardian’s desire to allow all devs to create public repos, but restrict the ability to create private repos - because we want to be open-by-default.

Repo-Genesis needs to be able to create a repository, that’s not currently available to Integrations.

submitGit - (not a Guardian bot, just one I wrote)

Needs to be able to write comments on PRs (“pull requests” permission), and in the future possibly close PRs - I think this is all already catered for with Integrations. The user would still need to authenticate themselves to use submitGit, as it sends email on their behalf.


Thanks for the detailed walk through of those use cases @rtyley. It’s helpful to see what would be needed to get things moved over and your initial read of things before jumping in.

I recently created a separate thread for additional endpoint requests over here. It would be great if you could extract the specific endpoints you’d need and document those for over there.