mirror of
https://github.com/actions/labeler.git
synced 2025-12-10 19:50:54 +00:00
Merge branch 'main'
This commit is contained in:
119
README.md
119
README.md
@@ -57,6 +57,11 @@ label1:
|
||||
|
||||
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. If path globs are combined with `!` negation, you can write complex matching rules.
|
||||
|
||||
> ⚠️ This action uses [minimatch](https://www.npmjs.com/package/minimatch) to apply glob patterns.
|
||||
> For historical reasons, paths starting with dot (e.g. `.github`) are not matched by default.
|
||||
> You need to set `dot: true` to change this behavior.
|
||||
> See [Inputs](#inputs) table below for details.
|
||||
|
||||
#### Basic Examples
|
||||
|
||||
```yml
|
||||
@@ -121,7 +126,7 @@ release:
|
||||
|
||||
### 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://help.github.com/en/articles/configuring-a-workflow#creating-a-workflow-file)) to utilize the labeler action with content:
|
||||
|
||||
```yml
|
||||
name: "Pull Request Labeler"
|
||||
@@ -142,12 +147,112 @@ jobs:
|
||||
|
||||
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`|
|
||||
| Name | Description | Default |
|
||||
|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|
|
||||
| `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`) | `false` |
|
||||
| `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@v3 # 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
|
||||
- uses: actions/labeler@v4
|
||||
```
|
||||
|
||||
##### Peculiarities of using the `dot` input
|
||||
|
||||
When `dot` is disabled, and you want to include _all_ files in a folder:
|
||||
|
||||
```yml
|
||||
label1:
|
||||
- path/to/folder/**/*
|
||||
- path/to/folder/**/.*
|
||||
```
|
||||
|
||||
If `dot` is enabled:
|
||||
|
||||
```yml
|
||||
label1:
|
||||
- path/to/folder/**
|
||||
```
|
||||
|
||||
##### Example workflow specifying Pull request numbers
|
||||
|
||||
```yml
|
||||
name: "Label Previous Pull Requests"
|
||||
on:
|
||||
schedule:
|
||||
- cron: "0 1 * * 1"
|
||||
|
||||
jobs:
|
||||
triage:
|
||||
permissions:
|
||||
contents: read
|
||||
pull-requests: write
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
|
||||
# Label PRs 1, 2, and 3
|
||||
- uses: actions/labeler@v4
|
||||
with:
|
||||
pr-number: |
|
||||
1
|
||||
2
|
||||
3
|
||||
```
|
||||
|
||||
**Note:** in normal usage the `pr-number` input is not required as the action will detect the PR number from the workflow context.
|
||||
|
||||
#### Outputs
|
||||
|
||||
Labeler provides the following outputs:
|
||||
|
||||
| Name | Description |
|
||||
|--------------|-----------------------------------------------------------|
|
||||
| `new-labels` | A comma-separated list of all new labels |
|
||||
| `all-labels` | A comma-separated list of all labels that the PR contains |
|
||||
|
||||
The following example performs steps based on the output of labeler:
|
||||
```yml
|
||||
name: "My workflow"
|
||||
on:
|
||||
- pull_request_target
|
||||
|
||||
jobs:
|
||||
triage:
|
||||
permissions:
|
||||
contents: read
|
||||
pull-requests: write
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- id: label-the-PR
|
||||
uses: actions/labeler@v4
|
||||
|
||||
- id: run-frontend-tests
|
||||
if: contains(steps.label-the-PR.outputs.all-labels, 'frontend')
|
||||
run: |
|
||||
echo "Running frontend tests..."
|
||||
# Put your commands for running frontend tests here
|
||||
|
||||
- id: run-backend-tests
|
||||
if: contains(steps.label-the-PR.outputs.all-labels, 'backend')
|
||||
run: |
|
||||
echo "Running backend tests..."
|
||||
# Put your commands for running backend tests here
|
||||
```
|
||||
|
||||
## 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. 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.
|
||||
|
||||
## Contributions
|
||||
|
||||
Contributions are welcome! See the [Contributor's Guide](CONTRIBUTING.md).
|
||||
|
||||
Reference in New Issue
Block a user