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.
- 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 v7](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@v7
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 `@v7.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
@ -53,7 +53,7 @@ All inputs are **optional**. If not set, sensible defaults will be used.
| `token` | The token that the action will use to create and update the pull request. See [token](#token). | `GITHUB_TOKEN` |
| `token` | The token that the action will use to create and update the pull request. See [token](#token). | `GITHUB_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` |
| `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>` |
@ -99,7 +99,7 @@ Other token options:
#### branch-token
#### branch-token
The action first creates a branch, and then creates a pull request for the branch.
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 neccessary, to use different tokens for these operations.
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.
It is not advisable to use this input unless you know you need to.
#### commit-message
#### commit-message
@ -131,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@v7
uses: peter-evans/create-pull-request@v8
env:
env:
https_proxy: http://<proxy_address>:<port>
https_proxy: http://<proxy_address>:<port>
```
```
@ -153,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@v7
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: |
@ -216,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@v7
uses: peter-evans/create-pull-request@v8
with:
with:
add-paths: |
add-paths: |
*.java
*.java
@ -230,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'
@ -243,29 +243,9 @@ 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@v7
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.
@ -40,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
```
```
@ -77,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.
@ -92,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@v7
- uses: peter-evans/create-pull-request@v8
with:
with:
base: ${{ github.head_ref }}
base: ${{ github.head_ref }}
```
```
@ -100,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@v7
- uses: peter-evans/create-pull-request@v8
with:
with:
base: main
base: main
```
```
@ -150,7 +150,7 @@ 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).
- Create draft pull requests by setting the `draft: always-true` input, and configure your workflow to trigger `on: ready_for_review`. 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.
- 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 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.
@ -179,14 +179,14 @@ This action uses [ncc](https://github.com/vercel/ncc) to compile the Node.js cod
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.
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@v7
- uses: peter-evans/create-pull-request@v8
with:
with:
token: ${{ secrets.PAT }}
token: ${{ secrets.PAT }}
```
```
@ -197,8 +197,9 @@ Checking out a branch from a different repository from where the workflow is exe
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]
> [!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.
> - 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.
> 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:
@ -209,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@v7
uses: peter-evans/create-pull-request@v8
```
```
### Push pull request branches to a fork
### Push pull request branches to a fork
@ -231,17 +232,17 @@ It will use their own fork to push code and create the pull request.
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 Classic [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) with `repo` scope.
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@v7
- 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
@ -271,7 +272,7 @@ The `token` input will then default to the repository's `GITHUB_TOKEN`, which wi
The following is an example of pushing to a fork using GitHub App tokens.
The following is an example of pushing to a fork using GitHub App tokens.
```yaml
```yaml
- uses: actions/create-github-app-token@v1
- uses: actions/create-github-app-token@v2
id: generate-token
id: generate-token
with:
with:
app-id: ${{ secrets.APP_ID }}
app-id: ${{ secrets.APP_ID }}
@ -279,12 +280,12 @@ The following is an example of pushing to a fork using GitHub App tokens.
- Under `Repository permissions: Workflows` select `Access: Read-only`.
- Under `Repository permissions: Workflows` select `Access: Read & write`.
- **NOTE**: Only needed if pull requests could contain changes to Actions workflows.
- **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.
@ -318,18 +319,18 @@ GitHub App generated tokens can be configured with fine-grained permissions and
```yaml
```yaml
steps:
steps:
- uses: actions/create-github-app-token@v1
- uses: actions/create-github-app-token@v2
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@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@v7
uses: peter-evans/create-pull-request@v8
with:
with:
token: ${{ steps.generate-token.outputs.token }}
token: ${{ steps.generate-token.outputs.token }}
```
```
@ -341,7 +342,7 @@ For this case a token must be generated from the GitHub App installation of the
In the following example, a pull request is being created in remote repo `owner/repo`.
In the following example, a pull request is being created in remote repo `owner/repo`.
```yaml
```yaml
steps:
steps:
- uses: actions/create-github-app-token@v1
- uses: actions/create-github-app-token@v2
id: generate-token
id: generate-token
with:
with:
app-id: ${{ secrets.APP_ID }}
app-id: ${{ secrets.APP_ID }}
@ -349,7 +350,7 @@ In the following example, a pull request is being created in remote repo `owner/
owner: owner
owner: owner
repositories: repo
repositories: repo
- uses: actions/checkout@v4
- uses: actions/checkout@v6
with:
with:
token: ${{ steps.generate-token.outputs.token }} # necessary if the repo is private
token: ${{ steps.generate-token.outputs.token }} # necessary if the repo is private
repository: owner/repo
repository: owner/repo
@ -357,7 +358,7 @@ In the following example, a pull request is being created in remote repo `owner/
# 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@v7
uses: peter-evans/create-pull-request@v8
with:
with:
token: ${{ steps.generate-token.outputs.token }}
token: ${{ steps.generate-token.outputs.token }}
```
```
@ -381,12 +382,12 @@ The action can sign commits as `github-actions[bot]` when using the repository's
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]`.
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
```yaml
steps:
steps:
- 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@v7
uses: peter-evans/create-pull-request@v8
with:
with:
sign-commits: true
sign-commits: true
```
```
@ -394,9 +395,9 @@ In this example the `token` input is not supplied, so the action will use the re
In this example, the `token` input is generated using a GitHub App. This will sign commits as `<application-name>[bot]`.
In this example, the `token` input is generated using a GitHub App. This will sign commits as `<application-name>[bot]`.
```yaml
```yaml
steps:
steps:
- uses: actions/checkout@v4
- uses: actions/checkout@v6
- uses: actions/create-github-app-token@v1
- uses: actions/create-github-app-token@v2
id: generate-token
id: generate-token
with:
with:
app-id: ${{ secrets.APP_ID }}
app-id: ${{ secrets.APP_ID }}
@ -405,7 +406,7 @@ In this example, the `token` input is generated using a GitHub App. This will si
# 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@v7
uses: peter-evans/create-pull-request@v8
with:
with:
token: ${{ steps.generate-token.outputs.token }}
token: ${{ steps.generate-token.outputs.token }}
sign-commits: true
sign-commits: true
@ -436,7 +437,7 @@ The action can use GPG to sign commits with a GPG key that you generate yourself
```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:
@ -448,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@v7
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@v7
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.
