Automating the GitHub *Nudge*

Git is a tool of Actions. Millions of times a day, users checkout, push, pull and merge submissions to their repositories. The scale is staggering:over 3.5 billion contributions were made on GitHub in 2022. That’s 227 million Pull Requests merged, and over 31 million issues closed. However, What about the PRs and the issues that fall through the cracks and are forgotten? Should they be just left, forgotten (like the Island of Misfit toys in Rudolf the RedNosed Reindeer?)

In this post, we introduce an automated RunBook that introduces the “Github nudge.” Merriam-Webster’s definition for a nudge is “to prod lightly : urge into action.” The GitHub nudge identifies issues and PRs that have been sitting a while, and “nudges” the assignee to take a look. By not letting the team forget that the issues exist – they are more likely to be acted upon!

We’ve defined a few Actions in unSkript’s RunBook architecture to help us along this path:

Stale Issues

When issues have been assigned to a team member, but no work is being done on them, the issue has probably “gotten lost.” Everyone has a lot to work on, and sometimes these issues just lose priority – or get superseded by other tasks. That does not mean that they should just be ignored – resolving the issue will improve the project.

In unSkript, there is an Action to find “stale” issues: that is issues that are over a certain age.

This Action takes 3 input parameters – the Github owner and repository and the threshold (in days) upon which you define an issue as stale. In the case of our repository https://github.com/unskript/Awesome-CloudOps-Automation, the owner is unskript, the repo is Awesome-CloudOps-Automation, and we set the stale threshold at 14 days. There’s no real science around that day -it felt like a good number for our team.

The response is an array of issues that surpass that threshold. With this data, we can do some quick examinations:

Issues without an assignee

Issues that have not been assigned to a resource are not going to be worked on – we all have a lot on our plate already! In the case of Awesome-CloudOps-Automation – these are all “good first issues” for those interested in contributing. I like to scan this list once a week for changes – and to ensure that issues that do need work are properly assigned.

Issues with an assignee

If an issue has been around for 2 weeks, and is not yet resolved – its good to check on them to see the status – and that action is being made:

For example – it appears that issue 346 is assigned to me, and I am overdue with an update (oops!):

{'assignee': NamedUser(login="dougsillars"),
   'issue_number': 346,
   'title': '[Action]: GitHub Comment on an issue'}

In this case, the PR was already merged, but not connected to the issue, so it could be closed (whew!).

Stale Pull Requests

We can do the same thing for Pull Requests:

A stale PR almost feels worse than a stale Issue. When the work is completed, and ready (perhaps nearly ready) to be integrated into the codebase – there is a immediate improvement to the software. When. PR just languishes, the code does not improve, and sometimes further improvements are blocked The Action above gives a list of all PRs that are over a threshold (again we use 14 days) for a given GitHub repository. For example:

{331: '3 cost optimization runbooks'}

This output does not provide anyone that I can ‘nudge’, but we have another Action that we can use:

To generate all of the reviewers to nudge, I first create a list of the PR numbers that I obtained from the first Action (the output was named “stalePull”:

oldPRs = []
for pr in stalePull[1]:
oldPRs.append(list(pr.keys())[0])
print(oldPRs)

The Get Pull Request Reviewer Action takes 3 inputs – owner, repository and PR number.

Using the iteration command in unSkript, we can apply the list of pull requests (oldPRs) to the pull_request_number variable:

This will call the Action once per pull request – giving a full output of each PR, and who is left to review.

331: ['jayasimha-raghavan-unskript', 'shloka-bhalgat-unskript']

With a little Python, we can turn this around to list every user, and the PRs they should look at.

U03QU1K184X': [267, 153]

You may notice that the username is different. This is in anticipation of the next step:

The actual “nudge”

Ok, so we know whose issues and PR reviews are overdue. How do we alert them? At unSkript, the internal team uses Slack. I have created a table that compares each Github username with their Slack ID (that’s the weird variable above).

With the slack ID, I can now send a message to the team channel:

If you are listed below, can you please review the Pull requests next to your name? They have been open for 14 days.

<@U01UG9DRR7D>, please review pull requests [267, 153].
<@U03QU1K184X>, please review pull requests [267, 153].

Adding the @ in front of the username creates an “at” in Slack, so these two users have just been effectively nudged to look at their PRs. They have now been nudged in Slack to go into GitHub and take a look at the work that is being forgotten.

Automating the Nudge!

Using the Enterprise version (or the free trial) of unSkript, you can schedule each RunBook. The RUnBook I created for Awesome-CloudOps-Automation runs every Wednesday morning – alerting the team that there are some issues and pull requests that have been left behind and should be resolved.

How do you keep your Github issues and Pull requests chugging along? Do you have suggestions on how you might improve this RunBook? We’d love to hear about it in the unSkript Slack channel. Interested in trying out Github nudges with your team? All of the Actions described above are in our Open source (Docker instructions are in the readme), and in our free Trial.