* Update README.md and labeler.ts to clarify permissions for GitHub Labeler Action
* Update dist/index.js with latest build changes
* Update README.md to clarify manual label creation as an alternative to granting issues write permission
* Fix labeler error handling to ensure case-insensitive check for unauthorized access
* Refactor error handling in labeler to throw an error for unauthorized access instead of logging
* Add tests for labeler error handling and improve error reporting
* 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
* fix: correct reading of sync-labels input.
Contrary to the assumptions made in the unit tests, core.getInput
always returns a string, and !!'false' is true.
Also updates the unit test to reduce changes of regressions by ensuring
that the mocked getInput returns a string, as it would in production.
Fixes https://github.com/actions/labeler/issues/112
Make sure test catches regressions.
* Rebuild dist/index.js.
As a means to reduce the privileges provided to the job executing, we
can document what the minimal `permissions` required for the Actions'
`GITHUB_TOKEN` is.
This is not intended to be a comprehensive test suite; I'm just trying to get us started by adding tests for some of the most important functionality.
This necessitated some minor refactoring. Previously, `main.ts` just directly invoked the main entrypoint function `run()`, which made it impossible to unit test the module without causing the side-effects of `run`.
As a workaround I created a new module `labeler.ts`, which just exports the functions we want to test without executing the main entrypoint, and simplified `main.ts` so that it only imports the entrypoint and executes it.
It's basically just a re-org. The diff makes it look way more complicated than it is.
- Document the release process in `CONTRIBUTING.md`
- Add development instructions to `CONTRIBUTING.md` (adapted from [download-artifact](https://github.com/actions/download-artifact))
- Add a test badge to the `README`
- Link to `CONTRIBUTING.md` in `README`
- Unify copy between `README.md` and `action.yml`
- Copy-pasta the CoC from [download-artifact](https://github.com/actions/download-artifact)
* Draft contributors.md update
This is a proposed updated to the contributors.md document inspired by
the contributing guidelines of the actions/cache project [1]. There are
some differences, most notable the inclusion of "Development Details"
which explains and motivates the development tools (to an extend).
--
1. eed9cfe64d/CONTRIBUTING.md
* Split Contributing Guidelines and Development Handbook
Split the "Contributing Guidelines" currently found in
docs/contributors.md into a CONTRIBUTING.md file, containing the
Contributing Guidelines, and a docs/development.md file, containing
details on how the development/testing of this project works.
With two configurations:
1. `* text=auto`: normalizes line endings for all files in the repo
2. `FILE -diff`: hides the diff of these files by default. I configured this
for lib/main.js and package-lock.json as they are not (intended to be)
human readable nor edited by humans. Hence, seeing their diff is mostly
useless.
The previous logic had a bug where the "any" pattern list could match
against changed files even when not all globs matched a single changed
file. The bug arose individual globs in the "any" list were tested
against all changed files individually. Therefore, as long as at least
one changed file matched an individual glob in the list, a successful
match would be found.
The correct behavior is to match all the globs in the list against each
individual file. This ensures that is possible to define exlcusions
correctly and matched the documented behavior.
* Add support for exclusions
Paths can be negated to stop searching through the remaining patterns in
a the glob list. All changed files tested and at least one matching file
will result in a label being added.
Fixesactions/labeler#9
* Add support for "AND"-ed matches
A new "rich" matcher object can be provided instead of a normal glob.
The matcher object has two fields that accept an array of globs:
* Globs in "all" must all match every changed file.
* Globs in "some" must all match at least one changed file.
Combined with negated globs, this allows for a precise control of when
labels are applied.
* Rename `some` to `any`
* Update README
* Fetch configuration content from PR ref
Fixes#6
When fetching the configuration content from the file specified by
`configuration-path`, we should load the content from the ref of the PR.
By default, `repos.getContents` will [use the repository's default
branch][1] if no `ref` is specified.
When first configuring this action, assuming the configuration file is
added in the same PR as the action, the configuration file will not
exist on the default branch. This causes an `HttpError: Not Found` to
occur when attempting to load the configuration from the default branch.
This commit updates the call to `getContents` to add the `ref`
parameter, set to the `GITHUB_SHA` value from the context. This will
cause the action to load the contents of the configuration file from the
ref of the PR, rather than the default branch.
---
This PR also updates the packages to use version 1.0.0 of all the
toolkit action packages, as they were using local files before.
I noticed that `src/main.ts` is not formatted according to the prettier
rules. I'm happy to open another PR that applies prettier to the current
source. I had to disable prettier during implementation of this commit
in order to keep the changes relevant to this PR.
[1]: https://developer.github.com/v3/repos/contents/#get-contents
* Remove exec, io, tool-cache
// This is a reusable configuration file copied from https://github.com/actions/reusable-workflows/tree/main/reusable-configurations. Please don't make changes to this file as it's the subject of an automatic update.
<!--- Please direct any generic questions related to actions to our support community forum at https://github.community/c/code-to-cloud/github-actions/41 --->
<!--- Before opening up a new bug report, please make sure to check for similar existing issues -->
**Description:**
A clear and concise description of what the bug is.
**Action version:**
Specify the action version
**Platform:**
- [ ] Ubuntu
- [ ] macOS
- [ ] Windows
**Runner type:**
- [ ] Hosted
- [ ] Self-hosted
**Repro steps:**
A description with steps to reproduce the issue. If your have a public example or repo to share, please provide the link.
<!--- Please direct any generic questions related to actions to our support community forum at https://github.community/c/code-to-cloud/github-actions/41 --->
<!--- Before opening up a new feature request, please make sure to check for similar existing issues and pull requests -->
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.
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.
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.
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: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:Octokit plugin to paginate REST API endpoint responses
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:Octokit plugin adding one method for all of api.github.com REST API endpoints
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: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: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:Get a user agent string in both browser and node
homepage:
license:isc
licenses:
- sources:LICENSE.md
text:|
# [ISC License](https://spdx.org/licenses/ISC)
Copyright (c) 2018, Gregor Martynus (https://github.com/gr2m)
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
// This is a reusable configuration file copied from https://github.com/actions/reusable-workflows/tree/main/reusable-configurations. Please don't make changes to this file as it's the subject of an automatic update.
Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](LICENSE).
Please note that this project is released with a [Contributor Code of Conduct][code-of-conduct]. By participating in this project you agree to abide by its terms.
## Found a bug?
- **Ensure the bug was not already reported** by searching on GitHub under [Issues](https://github.com/actions/labeler/issues).
- If you're unable to find an open issue addressing the problem, [open a new one](https://github.com/actions/labeler/issues/new). Be sure to include a **title and clear description**, as much relevant information as possible, and a **code sample** or a **reproducible test case** demonstrating the expected behavior that is not occurring.
- If possible, use the relevant bug report templates to create the issue.
## What should I know before submitting a pull request or issue
This project is written in [TypeScript](https://www.typescriptlang.org/), a typed variant of JavaScript, and we use [Prettier](https://prettier.io/) to get a consistent code style.
Because of how GitHub Actions are run, the source code of this project is transpiled from TypeScript into JavaScript. The transpiled code (found in `lib/`) is subsequently compiled using [NCC](https://github.com/vercel/ncc/blob/master/readme.md) (found in `dist/`) to avoid having to include the `node_modules/` directory in the repository.
## Submitting a pull request
1. [Fork][fork] and clone the repository
1. Configure and install the dependencies: `npm install`
1. Create a new branch: `git checkout -b my-branch-name`
1. Make your change, add tests, and make sure the tests still pass: `npm run test`
1. Make sure your code is correctly formatted: `npm run format`
1. Update `dist/index.js` using `npm run build`. This creates a single javascript file that is used as an entrypoint for the action
1. Push to your fork and [submit a pull request][pr]
1. Pat yourself on the back and wait for your pull request to be reviewed and merged.
Here are a few things you can do that will increase the likelihood of your pull request being accepted:
- Write tests.
- Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
## Releasing a new version
All the concepts from [the actions/toolkit release docs](https://github.com/actions/toolkit/blob/main/docs/action-versioning.md) apply. Please read that first!
Once the changes are merged into main, a repo maintainer should:
1. Bump the package version by running [`npm version [major|minor|patch]`](https://docs.npmjs.com/cli/v7/commands/npm-version). We adhere to [SemVer 2.0](https://semver.org/spec/v2.0.0.html) to the best of our ability. Commit the changes to `package.json` and `package-lock.json` and push them to main.
1. [Draft a new release](https://github.com/actions/labeler/releases/new) pointing to the ref of the version bump you just made. Publish the release to the marketplace when complete.
1. Finally: update the corresponding "major tag" (v1, v2, v3, etc) to point to the specific ref of the release you just made. For example, if we just released `v1.1.0`, we would rewrite the `v1` tag like this:
```
git tag -fa v1 v1.1.0 -m "Update v1 tag to point to v1.1.0"
git push origin v1 --force
```
## Licensed
This repository uses a tool called [Licensed](https://github.com/github/licensed) to verify third party dependencies. You may need to locally install licensed and run `licensed cache` to update the dependency cache if you install or update a production dependency. If licensed cache is unable to determine the dependency, you may need to modify the cache file yourself to put the correct license. You should still verify the dependency, licensed is a tool to help, but is not a substitute for human review of dependencies.
## Resources
- [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
To use, 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.
Automatically label new pull requests based on the paths of files being changed or the branch name.
Example:
## Breaking changes in V6
- Upgraded action from node20 to node24.
> Make sure your runner is on version v2.327.1 or later to ensure compatibility with this release. [Release Notes](https://github.com/actions/runner/releases/tag/v2.327.1)
For more details, see the full release notes on the [release page](https://github.com/actions/labeler/releases/tag/v6.0.0)
## 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 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 a match object.
#### Match Object
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
- 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']
```
label1:
- example1/**/*
label2: example2/*
There are two top-level keys, `any` and `all`, which both accept the same configuration options:
```yml
- 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']
```
label3:
- example3/*
- example3/**/*.yml
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/*'
```
Then create a workflow:
and
```yml
Documentation:
- any:
- changed-files:
- any-glob-to-any-file:'docs/*'
```
If path globs are combined with `!` negation, you can write complex matching rules. See the examples below for more information.
#### Basic Examples
```yml
# 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 'AnyChange' label to any changes within the entire repository
AnyChange:
- changed-files:
- any-glob-to-any-file:'**'
# 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/*
# Add 'Documentation' label to any file changes within 'docs' or 'guides' folders
Documentation:
- changed-files:
- any-glob-to-any-file:
- docs/*
- guides/*
## Equivalent of the above mentioned configuration using another syntax
Documentation:
- changed-files:
- any-glob-to-any-file:['docs/*','guides/*']
# 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:
- all:
- changed-files:
- any-glob-to-any-file:'src/**/*'
- all-globs-to-all-files:'!src/docs/*'
# 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 (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"
on:
- pull-request
on:
- pull_request_target
jobs:
triage:
labeler:
permissions:
contents:read
pull-requests:write
runs-on:ubuntu-latest
steps:
- uses: actions/labeler@v2
with:
repo-token: "${{ secrets.GITHUB_TOKEN }}"
- uses:actions/labeler@v6
```
#### Inputs
Various inputs are defined in [`action.yml`](action.yml) to let you configure the labeler:
| `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 |
##### 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
To successfully add labels to pull requests using the GitHub Labeler Action, specific permissions must be granted based on your use case:
1.**Adding Existing Labels**:
- Requires: `pull-requests: write`
- Use this if all labels already exist in the repository (i.e., pre-defined in `.github/labeler.yml`).
2.**Creating New Labels**:
- Requires: `issues: write`
- This is necessary if the action needs to create labels that do not already exist in the repository.
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 advisable 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.
### Example Workflow Permissions
To ensure the action works correctly, include the following permissions in your workflow file:
```yml
permissions:
contents:read
pull-requests:write
issues:write
```
### Manual Label Creation as an Alternative to Granting issues write Permission
If you prefer not to grant the `issues: write` permission in your workflow, you can manually create all required labels in the repository before the action runs.
## 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).
- Do not checkin devDependency node_modules (husky can help see below)
### devDependencies
In order to handle correctly checking in node_modules without devDependencies, we run [Husky](https://github.com/typicode/husky) before each commit.
This step ensures that formatting and checkin rules are followed and that devDependencies are excluded. To make sure Husky runs correctly, please use the following workflow:
```
npm install # installs all devDependencies including Husky
git add abc.ext # Add the files you've changed. This should include files in src, lib, and node_modules (see above)
git commit -m "Informative commit message" # Commit. This will run Husky
```
During the commit step, Husky will take care of formatting all files with [Prettier](https://github.com/prettier/prettier) as well as pruning out devDependencies using `npm prune --production`.
It will also make sure these changes are appropriately included in your commit (no further work is needed)
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.
> Core functions for setting results, logging, registering secrets and exporting variables across actions
## Usage
### Import the package
```js
// javascript
constcore=require('@actions/core');
// typescript
import*ascorefrom'@actions/core';
```
#### Inputs/Outputs
Action inputs can be read with `getInput`. Outputs can be set with `setOutput` which makes them available to be mapped into inputs of other actions to ensure they are decoupled.
Since each step runs in a separate process, you can use `exportVariable` to add it to this step and future steps environment blocks.
```js
core.exportVariable('envVar','Val');
```
#### Setting a secret
Setting a secret registers the secret with the runner to ensure it is masked in logs.
```js
core.setSecret('myPassword');
```
#### PATH Manipulation
To make a tool's path available in the path for the remainder of the job (without altering the machine or containers state), use `addPath`. The runner will prepend the path given to the jobs PATH.
```js
core.addPath('/path/to/mytool');
```
#### Exit codes
You should use this library to set the failing exit code for your action. If status is not set and the script runs to completion, that will lead to a success.
```js
constcore=require('@actions/core');
try{
// Do stuff
}
catch(err){
// setFailed logs the message and sets a failing exit code
core.setFailed(`Action failed with error ${err}`);
Finally, this library provides some utilities for logging. Note that debug logging is hidden from the logs by default. This behavior can be toggled by enabling the [Step Debug Logs](../../docs/action-debugging.md#step-debug-logs).
```js
constcore=require('@actions/core');
constmyInput=core.getInput('input');
try{
core.debug('Inside try block');
if(!myInput){
core.warning('myInput was not set');
}
if(core.isDebug()){
// curl -v https://github.com
}else{
// curl https://github.com
}
// Do stuff
core.info('Output to the actions build log')
}
catch(err){
core.error(`Error ${err}, action may still succeed though`);
}
```
This library can also wrap chunks of output in foldable groups.
Returns an authenticated Octokit client that follows the machine [proxy settings](https://help.github.com/en/actions/hosting-your-own-runners/using-a-proxy-server-with-self-hosted-runners). See https://octokit.github.io/rest.js for the API.
```js
constgithub=require('@actions/github');
constcore=require('@actions/core');
asyncfunctionrun(){
// This should be a token with access to your repository scoped in as a secret.
// The YML workflow will need to set myToken with the GitHub Secret Token
Finally, you can get the context of the current action:
```js
constgithub=require('@actions/github');
constcontext=github.context;
constnewIssue=awaitoctokit.issues.create({
...context.repo,
title:'New issue!',
body:'Hello Universe!'
});
```
## Webhook payload typescript definitions
The npm module `@octokit/webhooks` provides type definitions for the response payloads. You can cast the payload to these types for better type information.
First, install the npm module `npm install @octokit/webhooks`
A lightweight HTTP client optimized for use with actions, TypeScript with generics and async await.
## Features
- HTTP client with TypeScript generics and async/await/Promises
- Typings included so no need to acquire separately (great for intellisense and no versioning drift)
- [Proxy support](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners#using-a-proxy-server-with-self-hosted-runners) just works with actions and the runner
- Targets ES2019 (runner runs actions with node 12+). Only supported on node 12+.
- Basic, Bearer and PAT Support out of the box. Extensible handlers for others.
- Redirects supported
Features and releases [here](./RELEASES.md)
## Install
```
npm install @actions/http-client --save
```
## Samples
See the [HTTP](./__tests__) tests for detailed examples.
## Errors
### HTTP
The HTTP client does not throw unless truly exceptional.
* A request that successfully executes resulting in a 404, 500 etc... will return a response object with a status code and a body.
* Redirects (3xx) will be followed by default.
See [HTTP tests](./__tests__) for detailed examples.
## Debugging
To enable detailed console logging of all HTTP requests and responses, set the NODE_DEBUG environment varible:
```
export NODE_DEBUG=http
```
## Node support
The http-client is built using the latest LTS version of Node 12. It may work on previous node LTS versions but it's tested and officially supported on Node12+.
## Support and Versioning
We follow semver and will hold compatibility between major versions and increment the minor version with new features and capabilities (while holding compat).
## Contributing
We welcome PRs. Please create an issue and if applicable, a design before proceeding with code.
Update NPM dependencies and add 429 to the list of HttpCodes
## 1.0.6
Automatically sends Content-Type and Accept application/json headers for \<verb>Json() helper methods if not set in the client or parameters.
## 1.0.5
Adds \<verb>Json() helper methods for json over http scenarios.
## 1.0.4
Started to add \<verb>Json() helper methods. Do not use this release for that. Use >= 1.0.5 since there was an issue with types.
## 1.0.1 to 1.0.3
Adds proxy support.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
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.