Skip to content


Use this GitHub Action with your project

Add this Action to an existing workflow or create a new one.

View on Marketplace
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit

Bumps [typescript]( from 4.8.2 to 4.8.4.
- [Release notes](
- [Commits](microsoft/[email protected]v4.8.2...v4.8.4)

- dependency-name: typescript
  dependency-type: direct:development
  update-type: version-update:semver-patch

Signed-off-by: dependabot[bot] <[email protected]>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]>

Git stats


Failed to load latest commit information.

Pull Request Labeler

build and test status dependencies

Automatically label new pull requests based on the paths of files being changed.


Create .github/labeler.yml

Create a .github/labeler.yml file with a list of labels and minimatch globs to match to apply the label.

The key is the name of the label in your repository that you want to add (eg: "merge conflict", "needs-updating") and the value is the path (glob) of the changed files (eg: src/**/*, tests/*.spec.js) or a match object.

Match Object

For more control over matching, you can provide a match object instead of a simple path glob. The match object is defined as:

- any: ['list', 'of', 'globs']
  all: ['list', 'of', 'globs']

One or both fields can be provided for fine-grained matching. Unlike the top-level list, the list of path globs provided to any and all must ALL match against a path for the label to be applied.

The fields are defined as follows:

  • any: match ALL globs against ANY changed path
  • all: match ALL globs against ALL changed paths

A simple path glob is the equivalent to any: ['glob']. More specifically, the following two configurations are equivalent:

- example1/*


- any: ['example1/*']

From a boolean logic perspective, top-level match objects are OR-ed together and individual match rules within an object are AND-ed. Combined with ! negation, you can write complex matching rules.

Basic Examples

# Add 'label1' to any changes within 'example' folder or any subfolders
- example/**/*

# Add 'label2' to any file changes within 'example2' folder
label2: example2/*

Common Examples

# Add 'repo' label to any root file changes
- '*'

# Add '@domain/core' label to any change within the 'core' package
- package/core/*
- package/core/**/*

# Add 'test' label to any change to *.spec.js files within the source dir
- src/**/*.spec.js

# Add 'source' label to any change to src files within the source dir EXCEPT for the docs sub-folder
- any: ['src/**/*', '!src/docs/*']

# Add 'frontend` label to any change to *.js files as long as the `main.js` hasn't changed
- any: ['src/**/*.js']
  all: ['!src/main.js']

Create Workflow

Create a workflow (eg: .github/workflows/labeler.yml see Creating a Workflow file) to utilize the labeler action with content:

name: "Pull Request Labeler"
- pull_request_target

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

Note: This grants access to the GITHUB_TOKEN so the action can make calls to GitHub's rest API


Various inputs are defined in action.yml to let you configure the labeler:

Name Description Default
repo-token Token to use to authorize label changes. Typically the GITHUB_TOKEN secret, with contents:read and pull-requests:write access N/A
configuration-path The path to the label configuration file .github/labeler.yml
sync-labels Whether or not to remove labels when matching files are reverted or no longer changed by the PR false


Contributions are welcome! See the Contributor's Guide.