Add labels to GitHub pull requests#

Labels on issues and pull requests can make it easier to understand the content, but also make paying attention to what has changed and selecting them easier. If a pull request only has the label terraform for example it indicates that only infrastructure changes are in play.

While multiple GitHub Actions exist the two main solutions are Probot Autolabeler and GitHub Actions Labeler. The first solution is based on a GitHub App that must be installed and have permission to update pull requests, the second solution is based on a workflow that runs a GitHub Action.

Using Probot Autolabeler#

The GitHub App probot/autolabeler runs constantly as it is a third-party application that installs hooks in the GitHub repository and acts based on those hooks. It can be easily installed via apps/probot-autolabeler which allows you to install the application and give access.

The second step is to create the file .github/autolabeler.yml to specify which tags to add for which directories and files as shown in the example file below. The configuration to select files is pretty straightforward with wildcards like on a Linux server itself.

Example configuration file .github/autolabeler.yml#
tests: ["test", "molecule", "docker-compose.test.yml"]
documentation: ["*.md", "*.rst", "*.txt"]
configuration: [".github/*.yml", ".gitignore", ".gitattributes", ".vscode/", ".devcontainer/", ".editorconfig", ".yamllint.yml", ".ansible-lint"]
terraform: ["terraform/", "*.tf", "*.lock.hcl"]
ansible: ["ansible/", "ansible.cfg", ".ansible-lint", "molecule/"]
docker: ["Dockerfile", "docker-compose.yml", "docker-compose.test.yml"]
python: ["*.py", "requirements.txt", "Pipfile", "Pipfile.lock"]
github: [".github/"]
github_actions: [".github/workflows/"]
vscode: [".vscode/"]
policy: [".github/ISSUE_TEMPLATE", ".github/PULL_TEMPLATE", "LICENSE", ""]
# Pull request has files in it that it shouldn't!
broken: ["*.pem", "*.jks"]


While Probot Autolabeler is trusted by a lot of people, it is a third-party service with access to a repository.

Using GitHub Action Labeler#

The second option is to utilize GitHub Actions to execute actions/labeler when a pull request has been created, updated, or reopened. The first step is to create a YAML file to describe the configuration on when which labels should be applied. The format is very similar to the structure used by apps/probot-autolabeler with some extra options. The example below describes mostly the same policy as before.

Example configuration file .github/labeler.yml#
  - '.ansible-lint'
  - 'ansible.cfg'
  - 'ansible/*'
  - 'molecule/*'
  - '**/*.jks'
  - '**/*.pem'
  - '**/*.pyc'
  - '.github/*yml'
  - '.gitignore'
  - '.gitattributes'
  - '.vscode/*'
  - '.devcontainer/*'
  - '.editorconfig'
  - '.yamllint.yml'
  - '.ansible-lint'
  - '**/Dockerfile'
  - '**/docker-compose.yml'
  - '**/docker-compose.test.yml'
  - '**/*.md'
  - '**/*.rst'
  - '**/*.txt'
  - any: ['.github/*', '!.github/workflows/']
  - '.github/workflows/*'
  - '.github/ISSUE_TEMPLATE/*'
  - '.github/PULL_TEMPLATE/*'
  - ''
  - '**/*.py'
  - '**/requirements.txt'
  - '**/Pipfile'
  - '**/Pipfile.lock'
  - 'test/*'
  - 'molecule/*'
  - 'docker-compose.test.yml'
  - 'terraform/*'
  - '**/*.tf'
  - '**/*.lock.hcl'
  - '.vscode/*'

Now that configuration has been made to specify which labels to add, the next step is to add the workflow file. The example below is the generic example given by GitHub with one exception variable sync-labels have been turned on to also remove unused labels from a pull request.

Workflow file .github/workflows/labeler.yml for GitHub Actions#
name: "Pull Request Labeler"


      contents: read
      pull-requests: write
    runs-on: ubuntu-latest
      - uses: actions/[email protected]
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          sync-labels: true


GitHub Actions are consuming time and will be billed against your pipeline budget. For public repositories, this is unlimited for now, but for private repositories, you have to pay per minute executed.

Automatic labeling considerations#

Multiple solutions exist for label merge requests, but the two solutions described are basically two ways to accomplish it with these and other tools. Both are easy to set up and get going, but seeing the increase of attacks to harvest API keys the first solution GitHub Apps may not be suitable for some projects. An alternative is to run your own instance and register it as a GitHub App, but the benefits may not be there, and you just pay for the extra pipeline time.