Add the retry plugin to automatically retry requests that fail with
server errors (5xx status codes). Configure the plugin to exclude 429
(rate limit) from retries since that is already handled by the
throttling plugin.
- Add @octokit/plugin-retry dependency
- Register retry plugin in Octokit client
- Export retryOptions with doNotRetry list excluding 429
- Apply retryOptions in GitHubHelper constructor
Wrap the git remote prune command in a try-catch block to prevent
the action from failing if the prune operation fails. Instead, log
a warning message and allow the action to continue.
Fixes edge cases where the prune command may fail on self-hosted
runners but shouldn't block the pull request creation workflow.
* fix: GitHub API not providing details for existing PRs in private repos (#4064)
* fix: extract fallback into func getPullNumber
---------
Co-authored-by: Noah Miller <mike@stealthwing.com>
* GitCommandManager: add a function to get a file's contents at a specific revision
* use showFileAtRef instead of readFileBase64
* Teach GitCommandManager.exec about an object of exec parameters so we can add more
* Encode the showFiletRef output as base64 out of the gate
* Fix missing async for function
* Use Buffer.concat to avoid issues with partial data streams
* formatting
---------
Co-authored-by: gustavderdrache <alex.ford@determinate.systems>
* docs(README): clarify that an existing open PR is managed
* make it a little more concise
---------
Co-authored-by: Peter Evans <18365890+peter-evans@users.noreply.github.com>
The option suggested here (Read only) is not an option, and wouldn't mean/do anything - you can read these files if you have access to the repo files. The description says this is needed if the PR could change the workflow files, so you need "Read and Write". Pretty sure this is just a typo, copied from the line below instead of the line above.
* Add support for signed commits (#3055)
* formatting
* fix eslint and lint errors
* shift setting the base to before the push
* sign commits by default for testing
* add debug lines
* read to buffer not string and use non-legacy method to base64
* debug payload without contents
* disable linter for debug code
* fix filepath when using path input
* try to fix head repo
* remove commented code
* Try refactor of file changes
* add tests for building file changes
* add build file changes test for binary files
* refactor graphql code into github helper class
* build file changes even when there is no diff
* add function to get commit detail
* fix format
* build branch commits
* use source mode for deleted files
* try rest api route
* fix check for branch existence
* force push
* try fix base tree
* debug commit verification
* debug commit verification
* fix format and cleanup
* add executable mode file to test
* limit blob creation concurrency
* only build commits when feature enabled
* remove unused code
* update readme link
* update docs for commit signing
* fix capital letter
* update docs
* add throttling
* set default back to false
* output head sha and verified status
* log outputs
* fix head sha output
* default the operation output to none
* output retryafter for secondary rate limit
* use separate client for branch and pull operations
* add maintainer-can-modify input
* rename git-token to branch-token
* fix branch token input
* remove deprecated env output
* update docs
* fix doc
* update docs
* build branch commits when there is a diff with the base
* check verification status of head commit when not known
* fix verified output when no commit signing is being used
* draft always-true
* convert to draft on branch updates when there is a diff with base
* update docs with blob size limit
* catch errors during blob creation for debugging
* parse empty commits
* pass base commit to push signed commits
* use parent commit details in create commit
* use parent tree for base_tree
* multipart tree creation
* update docs
* update readme about the permissions of the default token
* fix edge case where changes are partially merged
* add updating documentation
* fix typo
* update major version
---------
Co-authored-by: Ravi <1299606+rustycl0ck@users.noreply.github.com>
- commits made during the workflow that have not been pushed
- commits made during the workflow that have not been pushed
2. Commit all changes to a new branch, or update an existing pull request branch.
2. Commit all changes to a new branch, or update an existing pull request branch.
3. Create a pull request to merge the new branch into the base—the branch checked out in the workflow.
3. Create or update a pull request to merge the branch into the base—the branch checked out in the workflow.
## Documentation
## Documentation
- [Concepts, guidelines and advanced usage](docs/concepts-guidelines.md)
- [Concepts, guidelines and advanced usage](docs/concepts-guidelines.md)
- [Examples](docs/examples.md)
- [Examples](docs/examples.md)
- [Updating to v6](docs/updating.md)
- [Updating between versions](docs/updating.md)
- [Common issues](docs/common-issues.md)
- [Common issues](docs/common-issues.md)
## Usage
## Usage
```yml
```yml
- uses: actions/checkout@v4
- uses: actions/checkout@v6
# Make changes to pull request here
# Make changes to pull request here
- name: Create Pull Request
- name: Create Pull Request
uses: peter-evans/create-pull-request@v6
uses: peter-evans/create-pull-request@v8
```
```
You can also pin to a [specific release](https://github.com/peter-evans/create-pull-request/releases) version in the format `@v6.x.x`
You can also pin to a [specific release](https://github.com/peter-evans/create-pull-request/releases) version in the format `@v8.x.x`
### Workflow permissions
### Workflow permissions
@ -48,14 +48,12 @@ For repositories belonging to an organization, this setting can be managed by ad
All inputs are **optional**. If not set, sensible defaults will be used.
All inputs are **optional**. If not set, sensible defaults will be used.
**Note**: If you want pull requests created by this action to trigger an `on: push` or `on: pull_request` workflow then you cannot use the default `GITHUB_TOKEN`. See the [documentation here](docs/concepts-guidelines.md#triggering-further-workflow-runs) for workarounds.
| Name | Description | Default |
| Name | Description | Default |
| --- | --- | --- |
| --- | --- | --- |
| `token` | `GITHUB_TOKEN` (permissions `contents: write` and `pull-requests: write`) or a `repo` scoped [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token). | `GITHUB_TOKEN` |
| `token` | The token that the action will use to create and update the pull request. See [token](#token). | `GITHUB_TOKEN` |
| `git-token` | The [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) that the action will use for git operations. | Defaults to the value of `token` |
| `branch-token` | The token that the action will use to create and update the branch. See [branch-token](#branch-token). | Defaults to the value of `token` |
| `path` | Relative path under `GITHUB_WORKSPACE` to the repository. | `GITHUB_WORKSPACE` |
| `path` | Relative path under `GITHUB_WORKSPACE` to the repository. | `GITHUB_WORKSPACE` |
| `add-paths` | A comma or newline-separated list of file paths to commit. Paths should follow git's [pathspec](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec) syntax. If no paths are specified, all new and modified files are added. See [Add specific paths](#add-specific-paths). | |
| `add-paths` | A comma or newline-separated list of file paths to commit. Paths should follow git's [pathspec](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec) syntax. See [Add specific paths](#add-specific-paths). | If no paths are specified, all new and modified files are added. |
| `commit-message` | The message to use when committing changes. See [commit-message](#commit-message). | `[create-pull-request] automated change` |
| `commit-message` | The message to use when committing changes. See [commit-message](#commit-message). | `[create-pull-request] automated change` |
| `committer` | The committer name and email address in the format `Display Name <email@address.com>`. Defaults to the GitHub Actions bot user on github.com. | `github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>` |
| `committer` | The committer name and email address in the format `Display Name <email@address.com>`. Defaults to the GitHub Actions bot user on github.com. | `github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>` |
| `author` | The author name and email address in the format `Display Name <email@address.com>`. Defaults to the user who triggered the workflow run. | `${{ github.actor }} <${{ github.actor_id }}+${{ github.actor }}@users.noreply.github.com>` |
| `author` | The author name and email address in the format `Display Name <email@address.com>`. Defaults to the user who triggered the workflow run. | `${{ github.actor }} <${{ github.actor_id }}+${{ github.actor }}@users.noreply.github.com>` |
@ -65,6 +63,7 @@ All inputs are **optional**. If not set, sensible defaults will be used.
| `branch-suffix` | The branch suffix type when using the alternative branching strategy. Valid values are `random`, `timestamp` and `short-commit-hash`. See [Alternative strategy](#alternative-strategy---always-create-a-new-pull-request-branch) for details. | |
| `branch-suffix` | The branch suffix type when using the alternative branching strategy. Valid values are `random`, `timestamp` and `short-commit-hash`. See [Alternative strategy](#alternative-strategy---always-create-a-new-pull-request-branch) for details. | |
| `base` | Sets the pull request base branch. | Defaults to the branch checked out in the workflow. |
| `base` | Sets the pull request base branch. | Defaults to the branch checked out in the workflow. |
| `push-to-fork` | A fork of the checked-out parent repository to which the pull request branch will be pushed. e.g. `owner/repo-fork`. The pull request will be created to merge the fork's branch into the parent's base. See [push pull request branches to a fork](docs/concepts-guidelines.md#push-pull-request-branches-to-a-fork) for details. | |
| `push-to-fork` | A fork of the checked-out parent repository to which the pull request branch will be pushed. e.g. `owner/repo-fork`. The pull request will be created to merge the fork's branch into the parent's base. See [push pull request branches to a fork](docs/concepts-guidelines.md#push-pull-request-branches-to-a-fork) for details. | |
| `sign-commits` | Sign commits as `github-actions[bot]` when using `GITHUB_TOKEN`, or your own bot when using [GitHub App tokens](docs/concepts-guidelines.md#authenticating-with-github-app-generated-tokens). See [commit signing](docs/concepts-guidelines.md#commit-signature-verification-for-bots) for details. | `false` |
| `title` | The title of the pull request. | `Changes by create-pull-request action` |
| `title` | The title of the pull request. | `Changes by create-pull-request action` |
| `body` | The body of the pull request. | `Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action` |
| `body` | The body of the pull request. | `Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action` |
| `body-path` | The path to a file containing the pull request body. Takes precedence over `body`. | |
| `body-path` | The path to a file containing the pull request body. Takes precedence over `body`. | |
@ -73,7 +72,35 @@ All inputs are **optional**. If not set, sensible defaults will be used.
| `reviewers` | A comma or newline-separated list of reviewers (GitHub usernames) to request a review from. | |
| `reviewers` | A comma or newline-separated list of reviewers (GitHub usernames) to request a review from. | |
| `team-reviewers` | A comma or newline-separated list of GitHub teams to request a review from. Note that a `repo` scoped [PAT](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token), or equivalent [GitHub App permissions](docs/concepts-guidelines.md#authenticating-with-github-app-generated-tokens), are required. | |
| `team-reviewers` | A comma or newline-separated list of GitHub teams to request a review from. Note that a `repo` scoped [PAT](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token), or equivalent [GitHub App permissions](docs/concepts-guidelines.md#authenticating-with-github-app-generated-tokens), are required. | |
| `milestone` | The number of the milestone to associate this pull request with. | |
| `milestone` | The number of the milestone to associate this pull request with. | |
| `draft` | Create a [draft pull request](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests). It is not possible to change draft status after creation except through the web interface. | `false` |
| `draft` | Create a [draft pull request](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests). Valid values are `true` (only on create), `always-true` (on create and update), and `false`. | `false` |
| `maintainer-can-modify` | Indicates whether [maintainers can modify](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork) the pull request. | `true` |
#### token
The token input defaults to the repository's `GITHUB_TOKEN`.
> [!IMPORTANT]
> - If you want pull requests created by this action to trigger an `on: push` or `on: pull_request` workflow then you cannot use the default `GITHUB_TOKEN`. See the [documentation here](docs/concepts-guidelines.md#triggering-further-workflow-runs) for further details.
> - If using the repository's `GITHUB_TOKEN` and your repository was created after 2nd February 2023, the [default permission is read-only](https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/). Elevate the [permissions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token#defining-access-for-the-github_token-permissions) in your workflow.
> ```yml
> permissions:
> contents: write
> pull-requests: write
> ```
Other token options:
- Classic [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) with `repo` scope.
- Fine-grained [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) with `contents: write` and `pull-requests: write` scopes.
- [GitHub App tokens](docs/concepts-guidelines.md#authenticating-with-github-app-generated-tokens) with `contents: write` and `pull-requests: write` scopes.
> [!TIP]
> If pull requests could contain changes to Actions workflows you may also need the `workflows` scope.
#### branch-token
The action first creates a branch, and then creates a pull request for the branch.
For some rare use cases it can be useful, or even necessary, to use different tokens for these operations.
It is not advisable to use this input unless you know you need to.
#### commit-message
#### commit-message
@ -104,7 +131,7 @@ If you want branches to be deleted immediately on merge then you should use GitH
For self-hosted runners behind a corporate proxy set the `https_proxy` environment variable.
For self-hosted runners behind a corporate proxy set the `https_proxy` environment variable.
```yml
```yml
- name: Create Pull Request
- name: Create Pull Request
uses: peter-evans/create-pull-request@v6
uses: peter-evans/create-pull-request@v8
env:
env:
https_proxy: http://<proxy_address>:<port>
https_proxy: http://<proxy_address>:<port>
```
```
@ -115,9 +142,10 @@ The following outputs can be used by subsequent workflow steps.
- `pull-request-number` - The pull request number.
- `pull-request-number` - The pull request number.
- `pull-request-url` - The URL of the pull request.
- `pull-request-url` - The URL of the pull request.
- `pull-request-operation` - The pull request operation performed by the action, `created`, `updated` or `closed`.
- `pull-request-operation` - The pull request operation performed by the action, `created`, `updated`, `closed` or `none`.
- `pull-request-head-sha` - The commit SHA of the pull request branch.
- `pull-request-head-sha` - The commit SHA of the pull request branch.
- `pull-request-branch` - The branch name of the pull request.
- `pull-request-branch` - The branch name of the pull request.
- `pull-request-commits-verified` - Whether GitHub considers the signature of the branch's commits to be verified; `true` or `false`.
Step outputs can be accessed as in the following example.
Step outputs can be accessed as in the following example.
Note that in order to read the step outputs the action step must have an id.
Note that in order to read the step outputs the action step must have an id.
@ -125,7 +153,7 @@ Note that in order to read the step outputs the action step must have an id.
```yml
```yml
- name: Create Pull Request
- name: Create Pull Request
id: cpr
id: cpr
uses: peter-evans/create-pull-request@v6
uses: peter-evans/create-pull-request@v8
- name: Check outputs
- name: Check outputs
if: ${{ steps.cpr.outputs.pull-request-number }}
if: ${{ steps.cpr.outputs.pull-request-number }}
run: |
run: |
@ -188,7 +216,7 @@ File changes that do not match one of the paths will be stashed and restored aft
```yml
```yml
- name: Create Pull Request
- name: Create Pull Request
uses: peter-evans/create-pull-request@v6
uses: peter-evans/create-pull-request@v8
with:
with:
add-paths: |
add-paths: |
*.java
*.java
@ -202,7 +230,7 @@ Note that the repository must be checked out on a branch with a remote, it won't
```yml
```yml
steps:
steps:
- uses: actions/checkout@v4
- uses: actions/checkout@v6
- name: Create commits
- name: Create commits
run: |
run: |
git config user.name 'Peter Evans'
git config user.name 'Peter Evans'
@ -215,25 +243,7 @@ Note that the repository must be checked out on a branch with a remote, it won't
- name: Uncommitted change
- name: Uncommitted change
run: date +%s > report.txt
run: date +%s > report.txt
- name: Create Pull Request
- name: Create Pull Request
uses: peter-evans/create-pull-request@v6
uses: peter-evans/create-pull-request@v8
```
### Create a project card
To create a project card for the pull request, pass the `pull-request-number` step output to [create-or-update-project-card](https://github.com/peter-evans/create-or-update-project-card) action.
@ -37,7 +37,7 @@ So the straightforward solution is to just not install them during the workflow
- If hooks are automatically enabled by a framework, use an option provided by the framework to disable them. For example, for Husky users, they can be disabled with the `--ignore-scripts` flag, or by setting the `HUSKY` environment variable when the action runs.
- If hooks are automatically enabled by a framework, use an option provided by the framework to disable them. For example, for Husky users, they can be disabled with the `--ignore-scripts` flag, or by setting the `HUSKY` environment variable when the action runs.
- [Creating pull requests in a remote repository using GitHub App generated tokens](#creating-pull-requests-in-a-remote-repository-using-github-app-generated-tokens)
- [Commit signing](#commit-signing)
- [Commit signature verification for bots](#commit-signature-verification-for-bots)
- [Running in a container or on self-hosted runners](#running-in-a-container-or-on-self-hosted-runners)
- [Running in a container or on self-hosted runners](#running-in-a-container-or-on-self-hosted-runners)
## Terminology
## Terminology
@ -36,7 +40,7 @@ For each [event type](https://docs.github.com/en/actions/reference/events-that-t
The default can be overridden by specifying a `ref` on checkout.
The default can be overridden by specifying a `ref` on checkout.
```yml
```yml
- uses: actions/checkout@v4
- uses: actions/checkout@v6
with:
with:
ref: develop
ref: develop
```
```
@ -73,7 +77,7 @@ jobs:
example:
example:
runs-on: ubuntu-latest
runs-on: ubuntu-latest
steps:
steps:
- uses: actions/checkout@v4
- uses: actions/checkout@v6
```
```
There may be use cases where it makes sense to execute the workflow on a branch that is not the base of the pull request. In these cases, the base branch can be specified with the `base` action input. The action will attempt to rebase changes made during the workflow on to the actual base.
There may be use cases where it makes sense to execute the workflow on a branch that is not the base of the pull request. In these cases, the base branch can be specified with the `base` action input. The action will attempt to rebase changes made during the workflow on to the actual base.
@ -88,7 +92,7 @@ In these cases, you *must supply* the `base` input so the action can rebase chan
Workflows triggered by [`pull_request`](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request) events will by default check out a merge commit. Set the `base` input as follows to base the new pull request on the current pull request's branch.
Workflows triggered by [`pull_request`](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request) events will by default check out a merge commit. Set the `base` input as follows to base the new pull request on the current pull request's branch.
```yml
```yml
- uses: peter-evans/create-pull-request@v6
- uses: peter-evans/create-pull-request@v8
with:
with:
base: ${{ github.head_ref }}
base: ${{ github.head_ref }}
```
```
@ -96,7 +100,7 @@ Workflows triggered by [`pull_request`](https://docs.github.com/en/actions/refer
Workflows triggered by [`release`](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#release) events will by default check out a tag. For most use cases, you will need to set the `base` input to the branch name of the tagged commit.
Workflows triggered by [`release`](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#release) events will by default check out a tag. For most use cases, you will need to set the `base` input to the branch name of the tagged commit.
```yml
```yml
- uses: peter-evans/create-pull-request@v6
- uses: peter-evans/create-pull-request@v8
with:
with:
base: main
base: main
```
```
@ -146,13 +150,15 @@ There are a number of workarounds with different pros and cons.
- Use the default `GITHUB_TOKEN` and allow the action to create pull requests that have no checks enabled. Manually close pull requests and immediately reopen them. This will enable `on: pull_request` workflows to run and be added as checks. To prevent merging of pull requests without checks erroneously, use [branch protection rules](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests).
- Use the default `GITHUB_TOKEN` and allow the action to create pull requests that have no checks enabled. Manually close pull requests and immediately reopen them. This will enable `on: pull_request` workflows to run and be added as checks. To prevent merging of pull requests without checks erroneously, use [branch protection rules](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests).
- Use a `repo` scoped [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) created on an account that has write access to the repository that pull requests are being created in. This is the standard workaround and [recommended by GitHub](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow). However, the PAT cannot be scoped to a specific repository so the token becomes a very sensitive secret. If this is a concern, the PAT can instead be created for a dedicated [machine account](https://docs.github.com/en/github/site-policy/github-terms-of-service#3-account-requirements) that has collaborator access to the repository. Also note that because the account that owns the PAT will be the creator of pull requests, that user account will be unable to perform actions such as request changes or approve the pull request.
- Create draft pull requests by setting the `draft: always-true` input, and configure your workflow to trigger `ready_for_review` in `on: pull_request`. The workflow will run when users manually click the "Ready for review" button on the draft pull requests. If the pull request is updated by the action, the `always-true` mode ensures that the pull request will be converted back to a draft.
- Use a [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) created on an account that has write access to the repository that pull requests are being created in. This is the standard workaround and [recommended by GitHub](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow). It's advisable to use a dedicated [machine account](https://docs.github.com/en/github/site-policy/github-terms-of-service#3-account-requirements) that has collaborator access to the repository, rather than creating a PAT on a personal user account. Also note that because the account that owns the PAT will be the creator of pull requests, that user account will be unable to perform actions such as request changes or approve the pull request.
- Use [SSH (deploy keys)](#push-using-ssh-deploy-keys) to push the pull request branch. This is arguably more secure than using a PAT because deploy keys can be set per repository. However, this method will only trigger `on: push` workflows.
- Use [SSH (deploy keys)](#push-using-ssh-deploy-keys) to push the pull request branch. This is arguably more secure than using a PAT because deploy keys can be set per repository. However, this method will only trigger `on: push` workflows.
- Use a [machine account that creates pull requests from its own fork](#push-pull-request-branches-to-a-fork). This is the most secure because the PAT created only grants access to the machine account's fork, not the main repository. This method will trigger `on: pull_request` workflows to run. Workflows triggered `on: push` will not run because the push event is in the fork.
- Use a [machine account that creates pull requests from its own fork](#push-pull-request-branches-to-a-fork). This is the most secure because the PAT created only grants access to the machine account's fork, not the main repository. This method will trigger `on: pull_request` workflows to run. Workflows triggered `on: push` will not run because the push event is in the fork.
- Use a [GitHub App to generate a token](#authenticating-with-github-app-generated-tokens) that can be used with this action. GitHub App generated tokens are more secure than using a PAT because GitHub App access permissions can be set with finer granularity and are scoped to only repositories where the App is installed. This method will trigger both `on: push` and `on: pull_request` workflows.
- Use a [GitHub App to generate a token](#authenticating-with-github-app-generated-tokens) that can be used with this action. GitHub App generated tokens are more secure than using a Classic PAT because access permissions can be set with finer granularity and are scoped to only repositories where the App is installed. This method will trigger both `on: push` and `on: pull_request` workflows.
### Security
### Security
@ -170,26 +176,30 @@ This action uses [ncc](https://github.com/vercel/ncc) to compile the Node.js cod
### Creating pull requests in a remote repository
### Creating pull requests in a remote repository
Checking out a branch from a different repository from where the workflow is executing will make *that repository* the target for the created pull request. In this case, a `repo` scoped [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) is required.
Checking out a branch from a different repository from where the workflow is executing will make *that repository* the target for the created pull request. In this case, the `GITHUB_TOKEN` will not work and one of the other [token options](../README.md#token) must be used.
```yml
```yml
- uses: actions/checkout@v4
- uses: actions/checkout@v6
with:
with:
token: ${{ secrets.PAT }}
token: ${{ secrets.PAT }}
repository: owner/repo
repository: owner/repo
# Make changes to pull request here
# Make changes to pull request here
- uses: peter-evans/create-pull-request@v6
- uses: peter-evans/create-pull-request@v8
with:
with:
token: ${{ secrets.PAT }}
token: ${{ secrets.PAT }}
```
```
### Push using SSH (deploy keys)
### Push using SSH (deploy keys)
[Deploy keys](https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys) can be set per repository and so are arguably more secure than using a `repo` scoped [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token).
[Deploy keys](https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys) can be set per repository and so are arguably more secure than using a Classic [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token).
Allowing the action to push with a configured deploy key will trigger `on: push` workflows. This makes it an alternative to using a PAT to trigger checks for pull requests.
Allowing the action to push with a configured deploy key will trigger `on: push` workflows. This makes it an alternative to using a PAT to trigger checks for pull requests.
Note that you cannot use deploy keys alone to [create a pull request in a remote repository](#creating-pull-requests-in-a-remote-repository) because then using a PAT would become a requirement. This method only makes sense if creating a pull request in the repository where the workflow is running.
> [!NOTE]
> - You cannot use deploy keys alone to [create a pull request in a remote repository](#creating-pull-requests-in-a-remote-repository) because then using a PAT would become a requirement.
> This method only makes sense if creating a pull request in the repository where the workflow is running.
> - You cannot use deploy keys with [commit signature verification for bots](#commit-signature-verification-for-bots) (`sign-commits: true`).
How to use SSH (deploy keys) with create-pull-request action:
How to use SSH (deploy keys) with create-pull-request action:
@ -200,14 +210,14 @@ How to use SSH (deploy keys) with create-pull-request action:
```yml
```yml
steps:
steps:
- uses: actions/checkout@v4
- uses: actions/checkout@v6
with:
with:
ssh-key: ${{ secrets.SSH_PRIVATE_KEY }}
ssh-key: ${{ secrets.SSH_PRIVATE_KEY }}
# Make changes to pull request here
# Make changes to pull request here
- name: Create Pull Request
- name: Create Pull Request
uses: peter-evans/create-pull-request@v6
uses: peter-evans/create-pull-request@v8
```
```
### Push pull request branches to a fork
### Push pull request branches to a fork
@ -216,33 +226,76 @@ Instead of pushing pull request branches to the repository you want to update, y
This allows you to employ the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) by using a dedicated user acting as a [machine account](https://docs.github.com/en/github/site-policy/github-terms-of-service#3-account-requirements).
This allows you to employ the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) by using a dedicated user acting as a [machine account](https://docs.github.com/en/github/site-policy/github-terms-of-service#3-account-requirements).
This user only has `read` access to the main repository.
This user only has `read` access to the main repository.
It will use their own fork to push code and create the pull request.
It will use their own fork to push code and create the pull request.
Note that if you choose to use this method (not give the machine account `write` access to the repository) the following inputs cannot be used: `labels`, `assignees`, `reviewers`, `team-reviewers` and `milestone`.
> [!NOTE]
> If you choose to not give the machine account `write` access to the parent repository, the following inputs cannot be used: `labels`, `assignees`, `reviewers`, `team-reviewers` and `milestone`.
1. Create a new GitHub user and login.
1. Create a new GitHub user and login.
2. Fork the repository that you will be creating pull requests in.
2. Fork the repository that you will be creating pull requests in.
3. Create a [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token).
3. Create a Classic [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) with `repo` and `workflow` scopes.
4. Logout and log back into your main user account.
4. Logout and log back into your main user account.
5. Add a secret to your repository containing the above PAT.
5. Add a secret to your repository containing the above PAT.
6. As shown in the following example workflow, set the `push-to-fork` input to the full repository name of the fork.
6. As shown in the following example workflow, set the `push-to-fork` input to the full repository name of the fork.
```yaml
```yaml
- uses: actions/checkout@v4
- uses: actions/checkout@v6
# Make changes to pull request here
# Make changes to pull request here
- uses: peter-evans/create-pull-request@v6
- uses: peter-evans/create-pull-request@v8
with:
with:
token: ${{ secrets.MACHINE_USER_PAT }}
token: ${{ secrets.MACHINE_USER_PAT }}
push-to-fork: machine-user/fork-of-repository
push-to-fork: machine-user/fork-of-repository
```
```
Note: You can also combine `push-to-fork` with [creating pull requests in a remote repository](#creating-pull-requests-in-a-remote-repository).
> [!TIP]
> You can also combine `push-to-fork` with [creating pull requests in a remote repository](#creating-pull-requests-in-a-remote-repository).
#### Pushing to a fork with fine-grained permissions
Using a fine-grained [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) or [GitHub App](#authenticating-with-github-app-generated-tokens) with `push-to-fork` can be achieved, but comes with some caveats.
When using `push-to-fork`, the action needs permissions for two different repositories.
It needs `contents: write` for the fork to push the branch, and `pull-requests: write` for the parent repository to create the pull request.
There are two main scenarios:
1. The parent and fork have different owners. In this case, it's not possible to create a token that is scoped to both repositories so different tokens must be used for each.
2. The parent and fork both have the same owner (i.e. they exist in the same org). In this case, a single token can be scoped to both repositories, but the permissions granted cannot be different. So it would defeat the purpose of using `push-to-fork`, and you might as well just create the pull request directly on the parent repository.
For the first scenario, the solution is to scope the token for the fork, and use the `branch-token` input to push the branch.
The `token` input will then default to the repository's `GITHUB_TOKEN`, which will be used to create the pull request.
> [!NOTE]
> Solution limitations:
> - Since `GITHUB_TOKEN` will be used to create the pull request, the workflow *must* be executing in the parent repository where the pull request should be created.
> - `maintainer-can-modify`*must* be set to `false`, because the `GITHUB_TOKEN` will not have `write` access to the head branch in the fork.
The following is an example of pushing to a fork using GitHub App tokens.
### Authenticating with GitHub App generated tokens
### Authenticating with GitHub App generated tokens
A GitHub App can be created for the sole purpose of generating tokens for use with GitHub actions.
A GitHub App can be created for the sole purpose of generating tokens for use with GitHub actions.
These tokens can be used in place of `GITHUB_TOKEN` or a [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token).
GitHub App generated tokens can be configured with fine-grained permissions and are scoped to only repositories where the App is installed.
GitHub App generated tokens are more secure than using a PAT because GitHub App access permissions can be set with finer granularity and are scoped to only repositories where the App is installed.
1. Create a minimal [GitHub App](https://docs.github.com/en/developers/apps/creating-a-github-app), setting the following fields:
1. Create a minimal [GitHub App](https://docs.github.com/en/developers/apps/creating-a-github-app), setting the following fields:
@ -251,36 +304,115 @@ GitHub App generated tokens are more secure than using a PAT because GitHub App
- Uncheck `Active` under `Webhook`. You do not need to enter a `Webhook URL`.
- Uncheck `Active` under `Webhook`. You do not need to enter a `Webhook URL`.
- Under `Repository permissions: Contents` select `Access: Read & write`.
- Under `Repository permissions: Contents` select `Access: Read & write`.
- Under `Repository permissions: Workflows` select `Access: Read & write`.
- **NOTE**: Only needed if pull requests could contain changes to Actions workflows.
- Under `Organization permissions: Members` select `Access: Read-only`.
- Under `Organization permissions: Members` select `Access: Read-only`.
- **NOTE**: Only needed if you would like add teams as reviewers to PRs.
- **NOTE**: Only needed if you would like add teams as reviewers to PRs.
2. Create a Private key from the App settings page and store it securely.
2. Create a Private key from the App settings page and store it securely.
3. Install the App on any repository where workflows will run requiring tokens.
3. Install the App on repositories that the action will require access to in order to create pull requests.
4. Set secrets on your repository containing the GitHub App ID, and the private key you created in step 2. e.g. `APP_ID`, `APP_PRIVATE_KEY`.
4. Set secrets on your repository containing the GitHub App ID, and the private key you created in step 2. e.g. `APP_ID`, `APP_PRIVATE_KEY`.
5. The following example workflow shows how to use [tibdex/github-app-token](https://github.com/tibdex/github-app-token) to generate a token for use with this action.
5. The following example workflow shows how to use [actions/create-github-app-token](https://github.com/actions/create-github-app-token) to generate a token for use with this action.
```yaml
```yaml
steps:
steps:
- uses: actions/checkout@v4
- uses: actions/create-github-app-token@v2
- uses: tibdex/github-app-token@v1
id: generate-token
id: generate-token
with:
with:
app_id: ${{ secrets.APP_ID }}
app-id: ${{ secrets.APP_ID }}
private_key: ${{ secrets.APP_PRIVATE_KEY }}
private-key: ${{ secrets.APP_PRIVATE_KEY }}
- uses: actions/checkout@v6
# Make changes to pull request here
# Make changes to pull request here
- name: Create Pull Request
- name: Create Pull Request
uses: peter-evans/create-pull-request@v6
uses: peter-evans/create-pull-request@v8
with:
with:
token: ${{ steps.generate-token.outputs.token }}
token: ${{ steps.generate-token.outputs.token }}
```
```
### GPG commit signature verification
#### Creating pull requests in a remote repository using GitHub App generated tokens
For this case a token must be generated from the GitHub App installation of the remote repository.
In the following example, a pull request is being created in remote repo `owner/repo`.
```yaml
steps:
- uses: actions/create-github-app-token@v2
id: generate-token
with:
app-id: ${{ secrets.APP_ID }}
private-key: ${{ secrets.APP_PRIVATE_KEY }}
owner: owner
repositories: repo
- uses: actions/checkout@v6
with:
token: ${{ steps.generate-token.outputs.token }} # necessary if the repo is private
repository: owner/repo
# Make changes to pull request here
- name: Create Pull Request
uses: peter-evans/create-pull-request@v8
with:
token: ${{ steps.generate-token.outputs.token }}
```
### Commit signing
[Commit signature verification](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification) is a feature where GitHub will mark signed commits as "verified" to give confidence that changes are from a trusted source.
Some organizations require commit signing, and enforce it with branch protection rules.
The action supports two methods to sign commits, [commit signature verification for bots](#commit-signature-verification-for-bots), and [GPG commit signature verification](#gpg-commit-signature-verification).
#### Commit signature verification for bots
The action can sign commits as `github-actions[bot]` when using the repository's default `GITHUB_TOKEN`, or your own bot when using [GitHub App tokens](#authenticating-with-github-app-generated-tokens).
> [!IMPORTANT]
> - When setting `sign-commits: true` the action will ignore the `committer` and `author` inputs.
> - If you attempt to use a [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) the action will create the pull request, but commits will *not* be signed. Commit signing is only supported with bot generated tokens.
> - The GitHub API has a 40MiB limit when creating git blobs. An error will be raised if there are files in the pull request larger than this. If you hit this limit, use [GPG commit signature verification](#gpg-commit-signature-verification) instead.
In this example the `token` input is not supplied, so the action will use the repository's default `GITHUB_TOKEN`. This will sign commits as `github-actions[bot]`.
```yaml
steps:
- uses: actions/checkout@v6
# Make changes to pull request here
- name: Create Pull Request
uses: peter-evans/create-pull-request@v8
with:
sign-commits: true
```
In this example, the `token` input is generated using a GitHub App. This will sign commits as `<application-name>[bot]`.
```yaml
steps:
- uses: actions/checkout@v6
- uses: actions/create-github-app-token@v2
id: generate-token
with:
app-id: ${{ secrets.APP_ID }}
private-key: ${{ secrets.APP_PRIVATE_KEY }}
# Make changes to pull request here
- name: Create Pull Request
uses: peter-evans/create-pull-request@v8
with:
token: ${{ steps.generate-token.outputs.token }}
sign-commits: true
```
#### GPG commit signature verification
The action can use GPG to sign commits with a GPG key that you generate yourself.
The action can use GPG to sign commits with a GPG key that you generate yourself.
@ -300,11 +432,12 @@ The action can use GPG to sign commits with a GPG key that you generate yourself
6. The following example workflow shows how to use [crazy-max/ghaction-import-gpg](https://github.com/crazy-max/ghaction-import-gpg) to import your GPG key and allow the action to sign commits.
6. The following example workflow shows how to use [crazy-max/ghaction-import-gpg](https://github.com/crazy-max/ghaction-import-gpg) to import your GPG key and allow the action to sign commits.
Note that the `committer` email address *MUST* match the email address used to create your GPG key.
> [!IMPORTANT]
> The `committer` email address *MUST* match the email address used to create your GPG key.
```yaml
```yaml
steps:
steps:
- uses: actions/checkout@v4
- uses: actions/checkout@v6
- uses: crazy-max/ghaction-import-gpg@v5
- uses: crazy-max/ghaction-import-gpg@v5
with:
with:
@ -316,7 +449,7 @@ The action can use GPG to sign commits with a GPG key that you generate yourself
commit-message: Update swagger-ui to ${{ steps.swagger-ui.outputs.release_tag }}
commit-message: Update swagger-ui to ${{ steps.swagger-ui.outputs.release_tag }}
title: Update SwaggerUI to ${{ steps.swagger-ui.outputs.release_tag }}
title: Update SwaggerUI to ${{ steps.swagger-ui.outputs.release_tag }}
@ -324,7 +324,7 @@ jobs:
### Keep a fork up-to-date with its upstream
### Keep a fork up-to-date with its upstream
This example is designed to be run in a seperate repository from the fork repository itself.
This example is designed to be run in a separate repository from the fork repository itself.
The aim of this is to prevent committing anything to the fork's default branch would cause it to differ from the upstream.
The aim of this is to prevent committing anything to the fork's default branch would cause it to differ from the upstream.
In the following example workflow, `owner/repo` is the upstream repository and `fork-owner/repo` is the fork. It assumes the default branch of the upstream repository is called `main`.
In the following example workflow, `owner/repo` is the upstream repository and `fork-owner/repo` is the fork. It assumes the default branch of the upstream repository is called `main`.
@ -342,7 +342,7 @@ jobs:
updateFork:
updateFork:
runs-on: ubuntu-latest
runs-on: ubuntu-latest
steps:
steps:
- uses: actions/checkout@v4
- uses: actions/checkout@v6
with:
with:
repository: fork-owner/repo
repository: fork-owner/repo
- name: Reset the default branch with upstream changes
- name: Reset the default branch with upstream changes
@ -540,7 +540,7 @@ Note that the step where output variables are defined must have an id.
echo "pr_title=$pr_title" >> $GITHUB_OUTPUT
echo "pr_title=$pr_title" >> $GITHUB_OUTPUT
echo "pr_body=$pr_body" >> $GITHUB_OUTPUT
echo "pr_body=$pr_body" >> $GITHUB_OUTPUT
- name: Create Pull Request
- name: Create Pull Request
uses: peter-evans/create-pull-request@v6
uses: peter-evans/create-pull-request@v8
with:
with:
title: ${{ steps.vars.outputs.pr_title }}
title: ${{ steps.vars.outputs.pr_title }}
body: ${{ steps.vars.outputs.pr_body }}
body: ${{ steps.vars.outputs.pr_body }}
@ -566,7 +566,7 @@ The template is rendered using the [render-template](https://github.com/chuhlomi
bar: that
bar: that
- name: Create Pull Request
- name: Create Pull Request
uses: peter-evans/create-pull-request@v6
uses: peter-evans/create-pull-request@v8
with:
with:
body: ${{ steps.template.outputs.result }}
body: ${{ steps.template.outputs.result }}
```
```
@ -612,3 +612,30 @@ To enable step debug logging set the secret `ACTIONS_STEP_DEBUG` to `true` in th
MATRIX_CONTEXT: ${{ toJson(matrix) }}
MATRIX_CONTEXT: ${{ toJson(matrix) }}
run: echo "$MATRIX_CONTEXT"
run: echo "$MATRIX_CONTEXT"
```
```
### Show an annotation message for a created pull request
Showing an annotation message for a created or updated pull request allows you to confirm the pull request easily, such as by visiting the link. This can be achieved by adding a step that uses the [`notice` workflow command](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions?tool=bash#setting-a-notice-message).
In this example, when a pull request is created, you will be able to see the following message on an action run page (e.g., `/actions/runs/12812393039`):
```
https://github.com/peter-evans/create-pull-request/pull/1 was created.
- If using self-hosted runners or GitHub Enterprise Server, there are minimum requirements for `v8` to run. See "What's new" below for details.
### What's new
- Updated runtime to Node.js 24
- The action now requires a minimum version of [v2.327.1](https://github.com/actions/runner/releases/tag/v2.327.1) for the Actions runner. Update self-hosted runners to v2.327.1 or later to ensure compatibility.
## Updating from `v6` to `v7`
### Behaviour changes
- Action input `git-token` has been renamed `branch-token`, to be more clear about its purpose. The `branch-token` is the token that the action will use to create and update the branch.
- The action now handles requests that have been rate-limited by GitHub. Requests hitting a primary rate limit will retry twice, for a total of three attempts. Requests hitting a secondary rate limit will not be retried.
- The `pull-request-operation` output now returns `none` when no operation was executed.
- Removed deprecated output environment variable `PULL_REQUEST_NUMBER`. Please use the `pull-request-number` action output instead.
### What's new
- The action can now sign commits as `github-actions[bot]` when using `GITHUB_TOKEN`, or your own bot when using [GitHub App tokens](concepts-guidelines.md#authenticating-with-github-app-generated-tokens). See [commit signing](concepts-guidelines.md#commit-signature-verification-for-bots) for details.
- Action input `draft` now accepts a new value `always-true`. This will set the pull request to draft status when the pull request is updated, as well as on creation.
- A new action input `maintainer-can-modify` indicates whether [maintainers can modify](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork) the pull request. The default is `true`, which retains the existing behaviour of the action.
- A new output `pull-request-commits-verified` returns `true` or `false`, indicating whether GitHub considers the signature of the branch's commits to be verified.
