Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Improve readme #589

Merged
merged 2 commits into from
Jun 14, 2023
Merged

Improve readme #589

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1a5defc
spelling: e.g.
jsoref Jun 13, 2023
3240e30
Markdown: backticks
jsoref Jun 13, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
14 changes: 7 additions & 7 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Automatically label new pull requests based on the paths of files being changed.

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.

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 (e.g. `merge conflict`, `needs-updating`) and the value is the path (glob) of the changed files (e.g. `src/**`, `tests/*.spec.js`) or a match object.

#### Match Object

Expand Down Expand Up @@ -88,7 +88,7 @@ frontend:

### 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"
Expand All @@ -111,7 +111,7 @@ Various inputs are defined in [`action.yml`](action.yml) to let you configure th

| 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` |
| `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` |
| `dot` | Whether or not to auto-include paths starting with dot (e.g. `.github`) | `false` |
Expand All @@ -136,12 +136,12 @@ label1:
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.
`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)
[`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
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
Expand Down