💸Save up to $132K/month in CI costs!👉 Try Free
Skip to main content
← Back to workflows

How to automatically label pull requests GitHub Action?

actions/labeler -
GitHub Action
v5.0.0
1,939
Contributors
Contributor - joshdalesContributor - pje
Categories

Optimize Your CI/CD Pipeline

Get instant insights into your CI/CD performance and costs. Reduce build times by up to 45% and save on infrastructure costs.

45% Faster Builds
60% Cost Reduction
Usage
name: "Pull Request Labeler"
on:
- pull_request_target
jobs:
labeler:
permissions:
contents: read
pull-requests: write
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v5

labeler logo

labeler

An action for automatically labelling pull requests


Pull Request Labeler GitHub Action is a tool used within GitHub Actions for automatically applying labels to pull requests according to the path of files that have been changed. This can be very helpful in case of projects where various areas or components of the project need to be managed by different teams or else certain kinds of changes may invoke certain workflows or notifications.

How to Set Up and Update the Labeler Action Using Different GitHub Actions Event Triggers?

Setting up or updating a tool like a labeler action involves navigating the use of GitHub Actions event triggers, more so the pull_request_target, and pull_request. It will guide the control of workflow access to the code changes from pull requests that dictate both security and functionality.

Setting Up the Labeler Action with pull_request_target:

  1. Understanding the challenge. pull_request_target event works with the pull request from the base branch, not the pull request branch, and therefore majorly used for actions needing higher repository permissions.

    This simply means testing the action of the labeler that cannot be tested right on the original setups in the pull request where the labeler action is being introduced. Since the workflow will have no access to the potential changes in the configuration, which are done in a pull request by itself.

  2. Recommended Approach Commit the blind action of the labeler into the base branch, so it is a part of the main codebase for the repository. This is pretty much set up; it would need to be reviewed with great care and perhaps tested in some separate, non-production branch prior to being merged into the main branch.

How to temporarily update the major version of the labeler with pull_request:

  1. Identifying the Issue:

    • If the updates from such labeler action are being submitted via pull requests using pull_request_target, then this may make the trigger cause problems since it does rely on the code from the base branch.
  2. Temporary Fix

    • When you are updating, change the event trigger in your GitHub Actions workflow from pull_request_target to pull_request.
    • This would make the workflow run based on the code in the branch of that pull request, enabling the updated config files and labeler version to be accessed and used by the workflow.
  3. Steps to implement:

    "Pull Request Labeler"
    on:
    - pull_request
    • Make sure the new setup is all tested within the pull request to make sure everything functions as expected.
  4. Reverting the trigger.

    • If verified, switch back the workflow trigger to pull_request_target before merging your changes. This will make sure the workflow is still in possession of the required permissions needed for its further operations.