* Update Node.js version to 24 in action and dependencies
Bump the required Node.js version to 24 in action.yml and package.json. Update @types/node to ^24.1.0 to match the new Node.js version.
* package.json version update
* update to the latest versions
---------
Co-authored-by: Aparna Jyothi <aparnajyothi-y@github.com>
This workflow file publishes new action releases to the immutable action package of the same name as this repo.
This is part of the Immutable Actions project which is not yet fully released to the public. First party actions like this one are part of our initial testing of this feature.
* docs: add note about pull_request_target event trigger
* docs: change note from being caution to important
* docs: fix typos
* docs: add examples to the examples chapter
* docs: fix typos
I think this is a big gotcha that should be called out in the documentation. I've been trying to debug why the workflow did not run for a long time, until I finally understood the underlying issue.
* Make `jest-each` a devDependency
Change the dependency on `jest-each` from a regular dependency to a
development dependency (devDependency) as it is only used in tests.
* Remove `jest-each` and use `test-each` instead
* Early exit when no files are changed.
As a consequence of the `checkAll` function call returning `true` if the length of `changedFiles` is 0, this must early-exit in order to avoid labeling empty PRs.
* Update dist.
* Update for new code styles.
* review changes requested
* Update dist.
* chore: prettify code
---------
Co-authored-by: MaksimZhukov <maksimzhukov@github.com>
Co-authored-by: IvanZosimov <ivanzosimov@github.com>
* Adding pr-number as an optional parameter
* Updated README
* Tests on the pr-number parameter
* Added missing | to table
* re-built script
* Adding support for multiple pr-numbers
* excluded .idea
* Updated readme to reflect that there might be more than one PR
* Additional warning
* Removed unused
* Reformatted and re-built
* Corrected message
* Removed required check
* Added (s) to pull request numbers in the description
Co-authored-by: MaksimZhukov <46996400+MaksimZhukov@users.noreply.github.com>
* Reworded PR-number parameter description
Co-authored-by: MaksimZhukov <46996400+MaksimZhukov@users.noreply.github.com>
* adding getMultilineInput into the tests
* Fixing tests for single pr
* Fixing tests for multiple prs
* Updated README.md to make it more obvious that it can take a list of PRs
* Added example that labels PR's 1-3
* Handled no pull requests better (from code review)
* Handled no pull requests better (from code review)
* Handled missing pull request better (from code review)
* Back out suggested change as it broke the tests
* Rebuilt dist
* Update src/labeler.ts
Co-authored-by: MaksimZhukov <46996400+MaksimZhukov@users.noreply.github.com>
* Added Emphasis to the note
Co-authored-by: MaksimZhukov <46996400+MaksimZhukov@users.noreply.github.com>
* Changed mockInput for pr-number to be string[]
---------
Co-authored-by: MaksimZhukov <46996400+MaksimZhukov@users.noreply.github.com>
* Added output
* removed formatting changes
* more formatting changes
* Fix merge conflicts
* Small test refactoring
* tests are passing
* Add a test
* Add a small jest mock for addLabels. Not used.
* Add tests for more cases
* get rid of an unused jest mock
* fix review points
* rebuild + minor README fix
* fix review points
* update tests
* fix formatting
* add tests, fix bug
* cleanup
---------
Co-authored-by: Daniel Shteremberg <dshteremberg@labelbox.com>
Co-authored-by: Daniel Shteremberg <Daniel@Daniel-Shterembergs-MacBook-Pro.local>
Co-authored-by: Patrick Ellis <patrick.j.ellis@gmail.com>
Co-authored-by: Andrey Lobanovich <andrei.lobanovich@akvelon.com>
* push to excess labels to avoid reaching the limit
* build dist
* never set more than 100 labels
* use splice instead of set
* ignore IDE folders
* install @octokit/plugin-retry
* always setLabels
* fix indentations
* fix specs
* add spec for excess labels
* prettier
* licensed cache
* revert to !!core.getInput('sync-labels')
* better warning for exceeded labels
* keep manually-added labels
* nest the dedupe logic
* rename `removeLabel` to `removeLabelFromList` to avoid confusion
* use Sets, and issue a call only if labels have actually changed
* remove IDE config folders from gitignore
* remove obsolete duplucation check
---------
Co-authored-by: Mark Massoud <mark@unrealcloud.io>
An "Error: HttpError: Resource not accessible by integration" will be
encountered on pull requests with the wrong permissions.
Co-authored-by: AndreiLobanovich
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright (c) 2010-2020 Robert Kieffer and other contributors
Copyright 2019 GitHub
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
summary:Generated TypeScript definitions based on GitHub's OpenAPI spec for api.github.com
homepage:
license:mit
licenses:
- sources:LICENSE
text:|-
Copyright 2020 Gregor Martynus
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
summary:Shared TypeScript definitions for Octokit projects
homepage:
license:mit
licenses:
- sources:LICENSE
text:|
MIT License Copyright (c) 2019 Octokit contributors
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
summary:Implements the WebIDL algorithms for converting to and from JavaScript values
homepage:
license:bsd-2-clause
licenses:
- sources:LICENSE.md
text:|
# The BSD 2-Clause License
Copyright (c) 2014, Domenic Denicola
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Automatically label new pull requests based on the paths of files being changed.
Automatically label new pull requests based on the paths of files being changed or the branch name.
## Breaking changes in V5
1) The ability to apply labels based on the names of base and/or head branches was added ([#186](https://github.com/actions/labeler/issues/186) and [#54](https://github.com/actions/labeler/issues/54)). The match object for changed files was expanded with new combinations in order to make it more intuitive and flexible ([#423](https://github.com/actions/labeler/issues/423) and [#101](https://github.com/actions/labeler/issues/101)). As a result, the configuration file structure was significantly redesigned and is not compatible with the structure of the previous version. Please read the documentation below to find out how to adapt your configuration files for use with the new action version.
2) The bug related to the `sync-labels` input was fixed ([#112](https://github.com/actions/labeler/issues/112)). Now the input value is read correctly.
3) By default, `dot` input is set to `true`. Now, paths starting with a dot (e.g. `.github`) are matched by default.
4) Version 5 of this action updated the [runtime to Node.js 20](https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-javascript-actions). All scripts are now run with Node.js 20 instead of Node.js 16 and are affected by any breaking changes between Node.js 16 and 20.
> [!IMPORTANT]
> Before the update to the v5, please check out [this information](#notes-regarding-pull_request_target-event) about the `pull_request_target` event trigger.
## Usage
### Create `.github/labeler.yml`
Create a `.github/labeler.yml` file with a list of labels and [minimatch](https://github.com/isaacs/minimatch) globs to match to apply the label.
Create a `.github/labeler.yml` file with a list of labels and config options to match and 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.
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 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:
The match object allows control over the matching options. You can specify the label to be applied based on the files that have changed or the name of either the base branch or the head branch. For the changed files options you provide a [path glob](https://github.com/isaacs/minimatch#minimatch), and for the branches you provide a regexp to match against the branch name.
The base match object is defined as:
```yml
- any:['list','of','globs']
all:['list','of','globs']
- changed-files:
- any-glob-to-any-file:['list','of','globs']
- any-glob-to-all-files:['list','of','globs']
- all-globs-to-any-file:['list','of','globs']
- all-globs-to-all-files:['list','of','globs']
- base-branch:['list','of','regexps']
- head-branch:['list','of','regexps']
```
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:
There are two top-level keys, `any` and `all`, which both accept the same configuration options:
```yml
label1:
- example1/*
- any:
- changed-files:
- any-glob-to-any-file:['list','of','globs']
- any-glob-to-all-files:['list','of','globs']
- all-globs-to-any-file:['list','of','globs']
- all-globs-to-all-files:['list','of','globs']
- base-branch:['list','of','regexps']
- head-branch:['list','of','regexps']
- all:
- changed-files:
- any-glob-to-any-file:['list','of','globs']
- any-glob-to-all-files:['list','of','globs']
- all-globs-to-any-file:['list','of','globs']
- all-globs-to-all-files:['list','of','globs']
- base-branch:['list','of','regexps']
- head-branch:['list','of','regexps']
```
From a boolean logic perspective, top-level match objects, and options within `all` are `AND`-ed together and individual match rules within the `any` object are `OR`-ed.
One or all fields can be provided for fine-grained matching.
The fields are defined as follows:
-`all`: ALL of the provided options must match for the label to be applied
-`any`: if ANY of the provided options match then the label will be applied
-`base-branch`: match regexps against the base branch name
-`head-branch`: match regexps against the head branch name
-`changed-files`: match glob patterns against the changed paths
-`any-glob-to-any-file`: ANY glob must match against ANY changed file
-`any-glob-to-all-files`: ANY glob must match against ALL changed files
-`all-globs-to-any-file`: ALL globs must match against ANY changed file
-`all-globs-to-all-files`: ALL globs must match against ALL changed files
If a base option is provided without a top-level key, then it will default to `any`. More specifically, the following two configurations are equivalent:
```yml
Documentation:
- changed-files:
- any-glob-to-any-file:'docs/*'
```
and
```yml
label1:
- any:['example1/*']
Documentation:
- any:
- changed-files:
- any-glob-to-any-file:'docs/*'
```
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.
If path globs are combined with `!` negation, you can write complex matching rules. See the examples below for more information.
#### Basic Examples
```yml
# Add 'label1' to any changes within 'example' folder or any subfolders
label1:
- example/**/*
# Add 'root' label to any root file changes
# Quotation marks are required for the leading asterisk
root:
- changed-files:
- any-glob-to-any-file:'*'
# Add 'label2' to any file changes within 'example2' folder
label2:example2/*
# Add 'AnyChange' label to any changes within the entire repository
AnyChange:
- changed-files:
- any-glob-to-any-file:'**'
# Add label3 to any change to .txt files within the entire repository. Quotation marks are required for the leading asterisk
label3:
- '**/*.txt'
# Add 'Documentation' label to any changes within 'docs' folder or any subfolders
Documentation:
- changed-files:
- any-glob-to-any-file:docs/**
```
# Add 'Documentation' label to any file changes within 'docs' folder
Documentation:
- changed-files:
- any-glob-to-any-file:docs/*
#### Common Examples
# Add 'Documentation' label to any file changes within 'docs' or 'guides' folders
Documentation:
- changed-files:
- any-glob-to-any-file:
- docs/*
- guides/*
```yml
# Add 'repo' label to any root file changes
repo:
- '*'
## Equivalent of the above mentioned configuration using another syntax
Documentation:
- changed-files:
- any-glob-to-any-file:['docs/*','guides/*']
# Add '@domain/core' label to any change within the 'core' package
'@domain/core':
- package/core/*
- package/core/**/*
# Add 'test' label to any change to *.spec.js files within the source dir
test:
- src/**/*.spec.js
# Add 'Documentation' label to any change to .md files within the entire repository
Documentation:
- changed-files:
- any-glob-to-any-file:'**/*.md'
# Add 'source' label to any change to src files within the source dir EXCEPT for the docs sub-folder
source:
- any:['src/**/*','!src/docs/*']
- all:
- changed-files:
- any-glob-to-any-file:'src/**/*'
- all-globs-to-all-files:'!src/docs/*'
# Add 'frontend` label to any change to *.js files as long as the `main.js` hasn't changed
frontend:
- any:['src/**/*.js']
all:['!src/main.js']
# Add 'feature' label to any PR where the head branch name starts with `feature` or has a `feature` section in the name
feature:
- head-branch:['^feature','feature']
# Add 'release' label to any PR that is opened against the `main` branch
release:
- base-branch:'main'
```
### Create Workflow
Create a workflow (eg:`.github/workflows/labeler.yml` see [Creating a Workflow file](https://help.github.com/en/articles/configuring-a-workflow#creating-a-workflow-file)) to utilize the labeler action with content:
Create a workflow (e.g.`.github/workflows/labeler.yml` see [Creating a Workflow file](https://docs.github.com/en/actions/writing-workflows/quickstart#creating-your-first-workflow)) to utilize the labeler action with content:
```yml
name:"Pull Request Labeler"
@@ -92,25 +156,139 @@ on:
- pull_request_target
jobs:
triage:
labeler:
permissions:
contents:read
pull-requests:write
runs-on:ubuntu-latest
steps:
- uses:actions/labeler@v4
- uses:actions/labeler@v6
```
#### Inputs
Various inputs are defined in [`action.yml`](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 | `github.token` |
| `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`|
| `repo-token` | Token to use to authorize label changes. Typically the GITHUB_TOKEN secret | `github.token` |
| `configuration-path` | The path to the label configuration file. If the file doesn't exist at the specified path on the runner, action will read from the source repository via the Github API. | `.github/labeler.yml` |
| `sync-labels` | Whether or not to remove labels when matching files are reverted or no longer changed by the PR | `false`|
| `dot` | Whether or not to auto-include paths starting with dot (e.g. `.github`) | `true` |
| `pr-number` | The number(s) of pull request to update, rather than detecting from the workflow context | N/A |
# Contributions
##### Using `configuration-path` input together with the `@actions/checkout` action
You might want to use action called [@actions/checkout](https://github.com/actions/checkout) to upload label configuration file onto the runner from the current or any other repositories. See usage example below:
```yml
steps:
- uses:actions/checkout@v5# Uploads repository content to the runner
with:
repository:"owner/repositoryName"# The one of the available inputs, visit https://github.com/actions/checkout#readme to find more
# Put your commands for running backend tests here
```
## Recommended Permissions
In order to add labels to pull requests, the GitHub labeler action requires write permissions on the pull-request. However, when the action runs on a pull request from a forked repository, GitHub only grants read access tokens for `pull_request` events, at most. If you encounter an `Error: HttpError: Resource not accessible by integration`, it's likely due to these permission constraints. To resolve this issue, you can modify the `on:` section of your workflow to use
[`pull_request_target`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) instead of `pull_request` (see example [above](#create-workflow)). This change allows the action to have write access, because `pull_request_target` alters the [context of the action](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) and safely grants additional permissions. There exists a potentially dangerous misuse of the pull_request_target workflow trigger that may lead to malicious PR authors (i.e. attackers) being able to obtain repository write permissions or stealing repository secrets, Hence it is advisible that pull_request_target should only be used in workflows that are carefully designed to avoid executing untrusted code and to also ensure that workflows using pull_request_target limit access to sensitive resources. Refer to the [GitHub token permissions documentation](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) for more details about access levels and event contexts.
```yml
permissions:
contents:read
pull-requests:write
```
## Notes regarding `pull_request_target` event
Using the `pull_request_target` event trigger involves several peculiarities related to initial set up of the labeler or updating version of the labeler.
### Initial set up of the labeler action
When submitting an initial pull request to a repository using the `pull_request_target` event, the labeler workflow will not run on that pull request because the `pull_request_target` execution runs off the base branch instead of the pull request's branch. Unfortunately this means the introduction of the labeler can not be verified during that pull request and it needs to be committed blindly.
### Updating major version of the labeler
When submitting a pull request that includes updates of the labeler action version and associated configuration files, using the `pull_request_target` event may result in a failed workflow. This is due to the nature of `pull_request_target`, which uses the code from the base branch rather than the branch linked to the pull request — so, potentially outdated configuration files may not be compatible with the updated labeler action.
To prevent this issue, you can switch to using the `pull_request` event temporarily, before merging. This event execution draws from the code within the branch of your pull request, allowing you to verify the new configuration's compatibility with the updated labeler action.
```yml
name:"Pull Request Labeler"
on:
- pull_request
```
Once you confirm that the updated configuration files function as intended, you can then revert to using the `pull_request_target` event before merging the pull request. Following this step ensures that your workflow is robust and free from disruptions.
## Contributions
Contributions are welcome! See the [Contributor's Guide](CONTRIBUTING.md).
error.message!=='Resource not accessible by integration'
){
throwerror;
}
core.warning(
`The action requires write permission to add labels to pull requests. For more information please refer to the action documentation: https://github.com/actions/labeler#recommended-permissions`,
{
title:`${process.env['GITHUB_ACTION_REPOSITORY']} running under '${github.context.eventName}' is misconfigured`
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.