Privileged Requester

This GitHub Action will automatically approve pull requests based off of requester criteria defined in the target repository.

Use Case

Let's say you have a repository with a lot of dependabot PRs that are safe to automatically merge because you have a super duper robust test suite. You can use this Action to automatically approve pull requests from the dependabot user (or any other user you want).

Here are some bonus use cases:

• Automatically approve pull requests that were created by some automation that your team wrote
• Automatically approve pull requests that were created by a bot user that you have created
• Automatically approve pull requests that were created by a bot user that you have created and that have a specific label
• Automatically approve pull requests that were created by an admin/priviliged user for your project

Workflow Configuration

Here is an example of how to use this Action in its simplest form:

Where vX.X.X is the latest release version found on the releases page

name: privileged-requester
on:
  pull_request:
    types: [opened, synchronize, reopened, labeled, unlabeled]

permissions:
  pull-requests: write
  contents: read

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: github/privileged-requester@vX.X.X
        with:
          path: config/privileged-requester.yaml # the path on the repo's default branch where the privileged requester config can be found
          checkCommits: "true" # check to ensure all commits are made by the requester
          checkDiff: "true" # check to ensure the diff is only removals (no additions) - set to "false" to disable
          checkLabels: "true" # check to ensure the labels on the PR match those defined in the privileged requester config

Note: The config/privileged-requester.yaml file should be added to the default branch of the target repository before this workflow is run. Otherwise, the workflow will fail since it cannot find the configuration file.

See the example in the workflow folder

Requester Configuration

In the target repo, the privileged requester functionality should be configured like so:

---
requesters:
  dependabot[bot]:
    labels:
      - dependencies
      - github_actions

See the example in the config folder.

The location of this file in the target repo should be the path used in the workflow configuration path

Reviewer

This Action runs, by default, with the built-in GITHUB_TOKEN and so approves the PRs as the github-actions[bot] user.

However, you can configure the Action to run with a different repo scoped token - a bot user of your own - by defining the Workflow configuration option github_token pointing to the repo secret for that token.

Configuration

Here are the configuration options for this Action:

Inputs 📥

Input	Required?	Default	Description
github_token	yes	${{ github.token }}	The GitHub token used to create an authenticated client - Provided for you by default! - You can use the default provided token or you can provide a PAT as an alternative robot user token. Make sure this is a repository scoped token
handle	yes	'github-actions[bot]'	When using the default ${{ github.token }} (as seen above), the "handle" is fetched from this input since the token is repository scoped and it cannot even read its own handle. You should not need to change this input.
path	yes	config/privileged-requester.yaml	Path where the privileged requester configuration can be found
prCreator	yes	${{ github.event.pull_request.user.login }}	The creator of the PR for this pull request event
prNumber	yes	${{ github.event.pull_request.number }}	The number of the PR for this pull request event
checkCommits	yes	"true"	An option to check that every commit in the PR is made from the privileged requester
checkDiff	yes	"true"	An option to check that the PR diff only has a removal diff, with no additions - This option defaults to "true" but it can be disabled by setting it to "false"
checkLabels	yes	"true"	An option to check that the labels on the PR match those defined in the privileged requester config

Outputs 📤

Output	Description
approved	The string "true" if the privileged-requester approved the pull request

First Time Setup

It should be noted that this Action looks at the default branch for its configuration file. This means that if you add this Action through a pull request, it will look at the default branch and fail because it cannot find the config file that has not landed on main / master yet. After merging the pull request that adds this Action to your repository, it should work as expected.

GitHub App Permissions

If you are using a GitHub app with this Action, you will need to grant the following permissions:

• Checks: Read and write
• Contents: Read and write
• Metadata: Read-only
• Pull requests: Read and write

Subscribe to Events

This GitHub App will subscribe to the following events:

• Check suite
• Check run
• Pull request

Known Issues

Duplicate Approvals

There is logic built into this Action to try and prevent duplicate approvals from taking place. However, if you subscribe to many pull_request events in your Actions workflow you may see duplicate approvals. Here is an example of the workflow configuration that could cause this and why:

on:
  pull_request:
    types: [opened, synchronize, reopened, labeled, unlabeled]

Now if you were to open a pull request and apply labels to it during the creation process, you would likely see two approvals from this workflow (assuming you pass the privileged requester criteria). This is because the pull_request event is triggered twice - once for the opened event and once for the labeled event. If you want to avoid this, you can remove the labeled event from the workflow configuration or the opened event.