Permission is hereby granted, free of charge, to any person obtaining a copyof this software and associated documentation files (the "Software"), to dealin the Software without restriction, including without limitation the rightsto use, copy, modify, merge, publish, distribute, sublicense, and/or sellcopies of the Software, and to permit persons to whom the Software isfurnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in allcopies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THEAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, 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 THESOFTWARE.
A GitHub action to create a pull request for changes to your repository in the actions workspace.
Changes to a repository in the Actions workspace persist between steps in a workflow.This action is designed to be used in conjunction with other steps that modify or add files to your repository.The changes will be automatically committed to a new branch and a pull request created.
// This failure mode is a limitation of the action. Controlling your own commits cannot be used in detached HEAD state. // https://github.com/peter-evans/create-pull-request/issues/902 it('tests failure to create with commits on the working base (during the workflow) in detached HEAD state (WBNR)', async () => { // Checkout the HEAD commit SHA const headSha = await git.revParse('HEAD') await git.checkout(headSha)
// Create commits on the working base const commits = await createCommits(git) const commitMessage = uuidv4() const result = await createOrUpdateBranch( git, commitMessage, BASE, BRANCH, REMOTE_NAME, false, ADD_PATHS_DEFAULT ) // The action cannot successfully create the branch expect(result.action).toEqual('none') })})
# Clone a server-side fork of the base repocd $WORKINGDIRgit clone --mirror git://127.0.0.1/test-base.git /git/remote/test-fork.gitcd /git/remote/test-fork.gitgit log -1 --pretty=oneline
# Restore the working directorycd $WORKINGDIR
# Execute integration testsjest int --runInBand
49 __test__/git-auth-helper.int.test.ts
@@ -0,0 +1,49 @@import {GitCommandManager} from '../lib/git-command-manager'import {GitAuthHelper} from '../lib/git-auth-helper'
test('parseDisplayNameEmail fails to parse display name email formats', async () => { const displayNameEmail1 = 'abc@def.com' try { utils.parseDisplayNameEmail(displayNameEmail1) // Fail the test if an error wasn't thrown expect(true).toEqual(false) } catch (e: any) { expect(e.message).toEqual( `The format of '${displayNameEmail1}' is not a valid email address with display name` ) }
const displayNameEmail2 = ' < >' try { utils.parseDisplayNameEmail(displayNameEmail2) // Fail the test if an error wasn't thrown expect(true).toEqual(false) } catch (e: any) { expect(e.message).toEqual( `The format of '${displayNameEmail2}' is not a valid email address with display name` ) } })})
86 action.yml
@@ -0,0 +1,86 @@name: 'Create Pull Request'description: 'Creates a pull request for changes to your repository in the actions workspace'inputs: token: description: 'GITHUB_TOKEN or a `repo` scoped Personal Access Token (PAT)' default: ${{ github.token }} path: description: > Relative path under $GITHUB_WORKSPACE to the repository. Defaults to $GITHUB_WORKSPACE. add-paths: description: > A comma or newline-separated list of file paths to commit. Paths should follow git's pathspec syntax. Defaults to adding all new and modified files. commit-message: description: 'The message to use when committing changes.' default: '[create-pull-request] automated change' committer: description: > The committer name and email address in the format `Display Name <email@address.com>`. Defaults to the GitHub Actions bot user. default: 'GitHub <noreply@github.com>' author: description: > The author name and email address in the format `Display Name <email@address.com>`. Defaults to the user who triggered the workflow run. default: '${{ github.actor }} <${{ github.actor }}@users.noreply.github.com>' signoff: description: 'Add `Signed-off-by` line by the committer at the end of the commit log message.' default: false branch: description: 'The pull request branch name.' default: 'create-pull-request/patch' delete-branch: description: > Delete the `branch` when closing pull requests, and when undeleted after merging. Recommend `true`. default: false branch-suffix: description: 'The branch suffix type when using the alternative branching strategy.' base: description: > The pull request base branch. Defaults to the branch checked out in the workflow. push-to-fork: description: > 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. title: description: 'The title of the pull request.' default: 'Changes by create-pull-request action' body: description: 'The body of the pull request.' default: 'Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action' labels: description: 'A comma or newline separated list of labels.' assignees: description: 'A comma or newline separated list of assignees (GitHub usernames).' reviewers: description: 'A comma or newline separated list of reviewers (GitHub usernames) to request a review from.' team-reviewers: description: > A comma or newline separated list of GitHub teams to request a review from. Note that a `repo` scoped Personal Access Token (PAT) may be required. milestone: description: 'The number of the milestone to associate the pull request with.' draft: description: 'Create a draft pull request. It is not possible to change draft status after creation except through the web interface' default: falseoutputs: pull-request-number: description: 'The pull request number' pull-request-url: description: 'The URL of the pull request.' pull-request-operation: description: 'The pull request operation performed by the action, `created`, `updated` or `closed`.' pull-request-head-sha: description: 'The commit SHA of the pull request branch.'runs: using: 'node16' main: 'dist/index.js'branding: icon: 'git-pull-request' color: 'gray-dark'
const main = gitgraph.branch("main"); main.commit("Last commit on base"); const localMain = gitgraph.branch("<#1> main (local)"); localMain.commit({ subject: "<uncommittedchanges>", body: "Changes to the local base during the workflow", }) const remotePatch = gitgraph.branch("create-pull-request/patch"); remotePatch.merge({ branch: localMain, commitOptions: { subject: "[create-pull-request] automated change", body: "Changes pushed to create the remote branch", }, }); main.commit("New commit on base");
const localMain2 = gitgraph.branch("<#2> main (local)"); localMain2.commit({ subject: "<uncommittedchanges>", body: "Changes to the updated local base during the workflow", }) remotePatch.merge({ branch: localMain2, commitOptions: { subject: "[create-pull-request] automated change", body: "Changes force pushed to update the remote branch", }, });
main.merge(remotePatch);
</script>
</body>
</html>
BIN +108 KB docs/assets/cpr-gitgraph.png
Unable to render rich display
6 docs/assets/logo.svg
Unable to render rich display
BIN +327 KB docs/assets/pull-request-example.png
Unable to render rich display
371 docs/concepts-guidelines.md
@@ -0,0 +1,371 @@# Concepts, guidelines and advanced usage
This document covers terminology, how the action works, general usage guidelines, and advanced usage.
- [Terminology](#terminology)- [Events and checkout](#events-and-checkout)- [How the action works](#how-the-action-works)- [Guidelines](#guidelines) - [Providing a consistent base](#providing-a-consistent-base) - [Events which checkout a commit](#events-which-checkout-a-commit) - [Restrictions on repository forks](#restrictions-on-repository-forks) - [Triggering further workflow runs](#triggering-further-workflow-runs) - [Security](#security)- [Advanced usage](#advanced-usage) - [Creating pull requests in a remote repository](#creating-pull-requests-in-a-remote-repository) - [Push using SSH (deploy keys)](#push-using-ssh-deploy-keys) - [Push pull request branches to a fork](#push-pull-request-branches-to-a-fork) - [Authenticating with GitHub App generated tokens](#authenticating-with-github-app-generated-tokens) - [GPG commit signature verification](#gpg-commit-signature-verification) - [Running in a container or on self-hosted runners](#running-in-a-container-or-on-self-hosted-runners)
## Terminology
[Pull requests](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#about-pull-requests) are proposed changes to a repository branch that can be reviewed by a repository's collaborators before being accepted or rejected.
A pull request references two branches:
- The `base` of a pull request is the branch you intend to change once the proposed changes are merged.- The `branch` of a pull request represents what you intend the `base` to look like when merged. It is the `base` branch *plus* changes that have been made to it.
## Events and checkout
This action expects repositories to be checked out with the official GitHub Actions [checkout](https://github.com/actions/checkout) action.For each [event type](https://docs.github.com/en/actions/reference/events-that-trigger-workflows) there is a default `GITHUB_SHA` that will be checked out.
The default can be overridden by specifying a `ref` on checkout.
Unless the `base` input is supplied, the action expects the target repository to be checked out on the pull request `base`—the branch you intend to modify with the proposed changes.
Workflow steps:
1. Checkout the `base` branch2. Make changes3. Execute `create-pull-request` action
The following git diagram shows how the action creates and updates a pull request branch.
For the action to work correctly it should be executed in a workflow that checks out a *consistent* base branch. This will be the base of the pull request unless overridden with the `base` input.
This means your workflow should be consistently checking out the branch that you intend to modify once the PR is merged.
In the following example, the [`push`](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#push) and [`create`](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#create) events both trigger the same workflow. This will cause the checkout action to checkout inconsistent branches and commits. Do *not* do this. It will cause multiple pull requests to be created for each additional `base` the action is executed against.
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.
### Events which checkout a commit
The [default checkout](#events-and-checkout) for the majority of events will leave the repository checked out on a branch.However, some events such as `release` and `pull_request` will leave the repository in a "detached HEAD" state.This is because they checkout a commit, not a branch.In these cases, you *must supply* the `base` input so the action can rebase changes made during the workflow for the pull request.
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 [`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.
GitHub Actions have imposed restrictions on workflow runs triggered by public repository forks.Private repositories can be configured to [enable workflows](https://docs.github.com/en/github/administering-a-repository/disabling-or-limiting-github-actions-for-a-repository#enabling-workflows-for-private-repository-forks) from forks to run without restriction.
The restrictions apply to the `pull_request` event triggered by a fork opening a pull request in the upstream repository.
- Events from forks cannot access secrets, except for the default `GITHUB_TOKEN`. > With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. [GitHub Actions: Using encrypted secrets in a workflow](https://docs.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#using-encrypted-secrets-in-a-workflow)
- The `GITHUB_TOKEN` has read-only access when an event is triggered by a forked repository.
[GitHub Actions: Permissions for the GITHUB_TOKEN](https://docs.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token#permissions-for-the-github_token)
These restrictions mean that during a `pull_request` event triggered by a forked repository, actions have no write access to GitHub resources and will fail on any attempt.
A job condition can be added to prevent workflows from executing when triggered by a repository fork.
```ymlon: pull_requestjobs: example: runs-on: ubuntu-latest # Check if the event is not triggered by a fork if: github.event.pull_request.head.repo.full_name == github.repository```
For further reading regarding the security of pull requests, see this GitHub blog post titled [Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)
### Triggering further workflow runs
Pull requests created by the action using the default `GITHUB_TOKEN` cannot trigger other workflows. If you have `on: pull_request` or `on: push` workflows acting as checks on pull requests, they will not run.
> When you use the repository's `GITHUB_TOKEN` to perform tasks, events triggered by the `GITHUB_TOKEN` will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's `GITHUB_TOKEN`, a new workflow will not run even when the repository contains a workflow configured to run when `push` events occur.[GitHub Actions: Triggering a workflow from a workflow](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow)
#### Workarounds to trigger further workflow runs
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 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/reference/events-that-trigger-workflows#triggering-new-workflows-using-a-personal-access-token). 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.
- 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 [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.
### Security
From a security perspective it's good practice to fork third-party actions, review the code, and use your fork of the action in workflows.By using third-party actions directly the risk exists that it could be modified to do something malicious, such as capturing secrets.
Alternatively, use the action directly and reference the commit hash for the version you want to target.```yml - uses: thirdparty/foo-action@172ec762f2ac8e050062398456fccd30444f8f30```
This action uses [ncc](https://github.com/vercel/ncc) to compile the Node.js code and dependencies into a single JavaScript file under the [dist](https://github.com/peter-evans/create-pull-request/tree/main/dist) directory.
## Advanced usage
### 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.
```yml - uses: actions/checkout@v3 with: token: ${{ secrets.PAT }} repository: owner/repo # Make changes to pull request here - uses: peter-evans/create-pull-request@v4 with: token: ${{ secrets.PAT }}```
### 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).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.
How to use SSH (deploy keys) with create-pull-request action:
1. [Create a new SSH key pair](https://docs.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key) for your repository. Do not set a passphrase.2. Copy the contents of the public key (.pub file) to a new repository [deploy key](https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys) and check the box to "Allow write access."3. Add a secret to the repository containing the entire contents of the private key.4. As shown in the example below, configure `actions/checkout` to use the deploy key you have created.
```yml steps: - uses: actions/checkout@v3 with: ssh-key: ${{ secrets.SSH_PRIVATE_KEY }} # Make changes to pull request here - name: Create Pull Request uses: peter-evans/create-pull-request@v4```
### Push pull request branches to a fork
Instead of pushing pull request branches to the repository you want to update, you can push them to a fork of that repository.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.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`.
1. Create a new GitHub user and login.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).4. Logout and log back into your main user account.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.
```yaml - uses: actions/checkout@v3 # Make changes to pull request here - uses: peter-evans/create-pull-request@v4 with: token: ${{ secrets.MACHINE_USER_PAT }} push-to-fork: machine-user/fork-of-repository```
### Authenticating with GitHub App generated tokens
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 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:
- Set `GitHub App name`. - Set `Homepage URL` to anything you like, such as your GitHub profile page. - Uncheck `Active` under `Webhook`. You do not need to enter a `Webhook URL`. - Under `Repository permissions: Contents` select `Access: Read & write`. - Under `Repository permissions: Pull requests` select `Access: Read & write`. - Under `Organization permissions: Members` select `Access: Read-only`. - **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.
3. Install the App on any repository where workflows will run requiring tokens.
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.
The action can use GPG to sign commits with a GPG key that you generate yourself.
1. Follow GitHub's guide to [generate a new GPG key](https://docs.github.com/en/github/authenticating-to-github/generating-a-new-gpg-key).
2. [Add the public key](https://docs.github.com/en/github/authenticating-to-github/adding-a-new-gpg-key-to-your-github-account) to the user account associated with the [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) that you will use with the action.
3. Copy the private key to your clipboard, replacing `email@example.com` with the email address of your GPG key. ``` # macOS gpg --armor --export-secret-key email@example.com | pbcopy ```
4. Paste the private key into a repository secret where the workflow will run. e.g. `GPG_PRIVATE_KEY`
5. Create another repository secret for the key's passphrase, if applicable. e.g. `GPG_PASSPHRASE`
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.
### Running in a container or on self-hosted runners
This action can be run inside a container, or on [self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners), by installing the necessary dependencies.
This action requires `git` to be installed and on the `PATH`. Note that `actions/checkout` requires Git 2.18 or higher to be installed, otherwise it will just download the source of the repository instead of cloning it.
The following examples of running in a container show the dependencies being installed during the workflow, but they could also be pre-installed in a custom image.
- [Use case: Create a pull request to update X on push](#use-case-create-a-pull-request-to-update-x-on-push) - [Update project authors](#update-project-authors) - [Keep a branch up-to-date with another](#keep-a-branch-up-to-date-with-another)- [Use case: Create a pull request to update X on release](#use-case-create-a-pull-request-to-update-x-on-release) - [Update changelog](#update-changelog)- [Use case: Create a pull request to update X periodically](#use-case-create-a-pull-request-to-update-x-periodically) - [Update NPM dependencies](#update-npm-dependencies) - [Update Gradle dependencies](#update-gradle-dependencies) - [Update Cargo dependencies](#update-cargo-dependencies) - [Update SwaggerUI for GitHub Pages](#update-swaggerui-for-github-pages) - [Keep a fork up-to-date with its upstream](#keep-a-fork-up-to-date-with-its-upstream) - [Spider and download a website](#spider-and-download-a-website)- [Use case: Create a pull request to update X by calling the GitHub API](#use-case-create-a-pull-request-to-update-x-by-calling-the-github-api) - [Call the GitHub API from an external service](#call-the-github-api-from-an-external-service) - [Call the GitHub API from another GitHub Actions workflow](#call-the-github-api-from-another-github-actions-workflow)- [Use case: Create a pull request to modify/fix pull requests](#use-case-create-a-pull-request-to-modifyfix-pull-requests) - [autopep8](#autopep8)- [Misc workflow tips](#misc-workflow-tips) - [Filtering push events](#filtering-push-events) - [Dynamic configuration using variables](#dynamic-configuration-using-variables) - [Setting the pull request body from a file](#setting-the-pull-request-body-from-a-file) - [Using a markdown template](#using-a-markdown-template) - [Debugging GitHub Actions](#debugging-github-actions)
## Use case: Create a pull request to update X on push
This pattern will work well for updating any kind of static content based on pushed changes. Care should be taken when using this pattern in repositories with a high frequency of commits.
### Update project authors
Raises a pull request to update a file called `AUTHORS` with the git user names and email addresses of contributors.
```ymlname: Update AUTHORSon: push: branches: - mainjobs: updateAuthors: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 with: fetch-depth: 0 - name: Update AUTHORS run: | git log --format='%aN <%aE>%n%cN <%cE>' | sort -u > AUTHORS - name: Create Pull Request uses: peter-evans/create-pull-request@v4 with: commit-message: update authors title: Update AUTHORS body: Credit new contributors by updating AUTHORS branch: update-authors```### Keep a branch up-to-date with anotherThis is a use case where a branch should be kept up to date with another by opening a pull request to update it. The pull request should then be updated with new changes until it is merged or closed.In this example scenario, a branch called `production` should be updated via pull request to keep it in sync with `main`. Merging the pull request is effectively promoting those changes to production.```ymlname: Create production promotion pull requeston: push: branches: - mainjobs: productionPromotion: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 with: ref: production - name: Reset promotion branch run: | git fetch origin main:main git reset --hard main - name: Create Pull Request uses: peter-evans/create-pull-request@v4 with: branch: production-promotion```## Use case: Create a pull request to update X on releaseThis pattern will work well for updating any kind of static content based on the tagged commit of a release. Note that because `release` is one of the [events which checkout a commit](concepts-guidelines.md#events-which-checkout-a-commit) it is necessary to supply the `base` input to the action.### Update changelogRaises a pull request to update the `CHANGELOG.md` file based on the tagged commit of the release.Note that [git-chglog](https://github.com/git-chglog/git-chglog/) requires some configuration files to exist in the repository before this workflow will work.This workflow assumes the tagged release was made on a default branch called `main`.```ymlname: Update Changelogon: release: types: [published]jobs: updateChangelog: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 with: fetch-depth: 0 - name: Update Changelog run: | curl -o git-chglog -L https://github.com/git-chglog/git-chglog/releases/download/0.9.1/git-chglog_linux_amd64 chmod u+x git-chglog ./git-chglog -o CHANGELOG.md rm git-chglog - name: Create Pull Request uses: peter-evans/create-pull-request@v4 with: commit-message: update changelog title: Update Changelog body: Update changelog to reflect release changes branch: update-changelog base: main```## Use case: Create a pull request to update X periodicallyThis pattern will work well for updating any kind of static content from an external source. The workflow executes on a schedule and raises a pull request when there are changes.### Update NPM dependenciesThis workflow will create a pull request for npm dependencies.It works best in combination with a build workflow triggered on `push` and `pull_request`.A [Personal Access Token (PAT)](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) can be used in order for the creation of the pull request to trigger further workflows. See the [documentation here](concepts-guidelines.md#triggering-further-workflow-runs) for further details.```ymlname: Update Dependencieson: schedule: - cron: '0 10 * * 1'jobs: update-dep: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: '16.x' - name: Update dependencies run: | npx -p npm-check-updates ncu -u npm install - name: Create Pull Request uses: peter-evans/create-pull-request@v4 with: token: ${{ secrets.PAT }} commit-message: Update dependencies title: Update dependencies body: | - Dependency updates Auto-generated by [create-pull-request][1] [1]: https://github.com/peter-evans/create-pull-request branch: update-dependencies```The above workflow works best in combination with a build workflow triggered on `push` and `pull_request`.```ymlname: CIon: push: branches: [main] pull_request: branches: [main]jobs: build: runs-on:
87 docs/updating.md
@@ -0,0 +1,87 @@## Updating from `v3` to `v4`
### Breaking changes
- The `add-paths` input no longer accepts `-A` as a valid value. When committing all new and modified files the `add-paths` input should be omitted.
@@ -651,23 +2943,14 @@ To use `actions/checkout@v1` the following step to checkout the branch is necess
If neither `author` or `committer` are set the action will default to making commits as the GitHub Actions bot user.
### What's new
- Unpushed commits made during the workflow before the action runs will now be considered as changes to be raised in the pull request. See [Create your own commits](https://github.com/peter-evans/create-pull-request#create-your-own-commits) for details.- New commits made to the pull request base will now be taken into account when pull requests are updated.- If an updated pull request no longer differs from its base it will automatically be closed and the pull request branch deleted.
@@ -0,0 +1,294 @@import * as core from '@actions/core'import {GitCommandManager} from './git-command-manager'import {v4 as uuidv4} from 'uuid'
const CHERRYPICK_EMPTY = 'The previous cherry-pick is now empty, possibly due to conflict resolution.'const NOTHING_TO_COMMIT = 'nothing to commit, working tree clean'
@@ -0,0 +1,260 @@import * as core from '@actions/core'import { createOrUpdateBranch, getWorkingBaseAndType, WorkingBaseType} from './create-or-update-branch'import {GitHubHelper} from './github-helper'import {GitCommandManager} from './git-command-manager'import {GitAuthHelper} from './git-auth-helper'import * as utils from './utils'
export async function createPullRequest(inputs: Inputs): Promise<void> { let gitAuthHelper try { if (!inputs.token) { throw new Error(`Input 'token' not supplied. Unable to continue.`) }
@@ -714,9 +2995,7 @@ if (['created', 'updated'].includes(result.action)) { // The branch was created
// Set the base. It would have been '' if not specified as an input inputs.base = result.base
if (result.hasDiffWithBase) { // Create or update the pull request core.startGroup('Create or update the pull request') const pull = await githubHelper.createOrUpdatePullRequest( inputs, baseRemote.repository, branchRepository ) core.endGroup()
// Set outputs core.startGroup('Setting outputs') core.setOutput('pull-request-number', pull.number) core.setOutput('pull-request-url', pull.html_url) if (pull.created) { core.setOutput('pull-request-operation', 'created') } else if (result.action == 'updated') { core.setOutput('pull-request-operation', 'updated') } core.setOutput('pull-request-head-sha', result.headSha) // Deprecated core.exportVariable('PULL_REQUEST_NUMBER', pull.number) core.endGroup() } else { // There is no longer a diff with the base // Check we are in a state where a branch exists if (['updated', 'not-updated'].includes(result.action)) { core.info( `Branch '${inputs.branch}' no longer differs from base branch '${inputs.base}'` ) if (inputs.deleteBranch) { core.info(`Deleting branch '${inputs.branch}'`) await git.push([ '--delete', '--force', branchRemoteName, `refs/heads/${inputs.branch}` ]) // Set outputs core.startGroup('Setting outputs') core.setOutput('pull-request-operation', 'closed') core.endGroup() } } } } catch (error) { core.setFailed(utils.getErrorMessage(error)) } finally { // Remove auth and restore persisted auth config if it existed core.startGroup('Restore persisted git credentials') await gitAuthHelper.removeAuth() await gitAuthHelper.restorePersistedAuth() core.endGroup() }}
127 src/git-auth-helper.ts
@@ -0,0 +1,127 @@import * as core from '@actions/core'import * as fs from 'fs'import {GitCommandManager} from './git-command-manager'import * as path from 'path'import {URL} from 'url'import * as utils from './utils'
private async getAndUnset(): Promise<string> { let configValue = '' // Save and unset persisted extraheader credential in git config if it exists if ( await this.git.configExists( this.extraheaderConfigKey, this.extraheaderConfigValueRegex ) ) { configValue = await this.git.getConfigValue( this.extraheaderConfigKey, this.extraheaderConfigValueRegex ) if ( await this.git.tryConfigUnset( this.extraheaderConfigKey, this.extraheaderConfigValueRegex ) ) { core.info(`Unset config key '${this.extraheaderConfigKey}'`) } else { core.warning( `Failed to unset config key '${this.extraheaderConfigKey}'` ) } } return configValue }
private async gitConfigStringReplace( find: string, replace: string ): Promise<void> { let content = (await fs.promises.readFile(this.gitConfigPath)).toString() const index = content.indexOf(find) if (index <0||index!=content.lastIndexOf(find)){thrownewError(`Unabletoreplace'${find}'in${this.gitConfigPath}`)}content =content.replace(find,replace)awaitfs.promises.writeFile(this.gitConfigPath,content)}
private getServerUrl(): URL { // todo: remove GITHUB_URL after support for GHES Alpha is no longer needed // See https://github.com/actions/checkout/blob/main/src/url-helper.ts#L22-L29 return new URL( process.env['GITHUB_SERVER_URL'] || process.env['GITHUB_URL'] || 'https://github.com' ) }}
303 src/git-command-manager.ts
@@ -0,0 +1,303 @@import * as exec from '@actions/exec'import * as io from '@actions/io'import * as utils from './utils'import * as path from 'path'
const tagsRefSpec = '+refs/tags/*:refs/tags/*'
export class GitCommandManager { private gitPath: string private workingDirectory: string // Git options used when commands require an identity private identityGitOptions?: string[]
@@ -0,0 +1,183 @@import * as core from '@actions/core'import {Inputs} from './create-pull-request'import {Octokit, OctokitOptions} from './octokit-client'import * as utils from './utils'
const ERROR_PR_REVIEW_FROM_AUTHOR = 'Review cannot be requested from pull request author'
// Request reviewers and team reviewers const requestReviewersParams = {} if (inputs.reviewers.length > 0) { requestReviewersParams['reviewers'] = inputs.reviewers core.info(`Requesting reviewers '${inputs.reviewers}'`) } if (inputs.teamReviewers.length > 0) { requestReviewersParams['team_reviewers'] = inputs.teamReviewers core.info(`Requesting team reviewers '${inputs.teamReviewers}'`) } if (Object.keys(requestReviewersParams).length > 0) { try { await this.octokit.rest.pulls.requestReviewers({ ...this.parseRepository(baseRepository), pull_number: pull.number, ...requestReviewersParams }) } catch (e) { if (utils.getErrorMessage(e).includes(ERROR_PR_REVIEW_FROM_AUTHOR)) { core.warning(ERROR_PR_REVIEW_FROM_AUTHOR) } else { throw e } } }
return pull }}
38 src/main.ts
@@ -0,0 +1,38 @@import * as core from '@actions/core'import {Inputs, createPullRequest} from './create-pull-request'import {inspect} from 'util'import * as utils from './utils'
@@ -0,0 +1,28 @@import {Octokit as Core} from '@octokit/core'import {paginateRest} from '@octokit/plugin-paginate-rest'import {restEndpointMethods} from '@octokit/plugin-rest-endpoint-methods'import ProxyAgent from 'proxy-agent'export {RestEndpointMethodTypes} from '@octokit/plugin-rest-endpoint-methods'export {OctokitOptions} from '@octokit/core/dist-types/types'
https://www.gA. Amendments to Form D Content Requirements 1. Basic Identifying and Contact Information 2. Additional Information About Issuer 3. Identification of Claimed Exemptions and Exclusions 4. Indication of Type of Filing a. General Requirements b. Amendment of Previously Filed Form D 5. Information About Offering 6. Signature and Submission B. Electronic Filing of Form D C. General Solicitation and General Advertising Issues Presented by Electronic Filing of Form D III. ELECTRONIC FILING PROCEDURE A. Mechanics B. Database Capabilities of Electronic Form D Repository C. System Implementation IV. PAPERWORK REDUCTION ACT ANALYSIS V. COST-BENEFIT ANALYSIS VI. CONSIDERATION OF IMPACT ON COMPETITION AND PROMOTION OF EFFICIENCY, COMPETITION AND CAPITAL FORMATION VII. FINAL REGULATORY FLEXIBILITY ACT ANALYSIS VIII. STATUTORY BASIS AND TEXT OF AMENDMENTSovinfo.gov/content/pkg/COMPS-1879/pdf/COMPS-1879.pdf uses: actions/checkout@v2
uses:
Re:
Direct Deposit
Paid to Zachry Tyler Wood for Deposit to Personal C&S Business Accounts listed Below
On Wed, Dec 29, 2021, 10:26 PM Zachry Wood <zachrywood10@gmail.com> Amendments: to Form D Content Requirements 1. Basic Identifying and Contact Information 2. Additional Information About Issuer 3. Identification of Claimed Exemptions and Exclusions 4. Indication of Type of Filing a. General Requirements b. Amendment of Previously Filed Form D 5. Information About Offering 6. Signature and Submission B. Electronic Filing of Form D C. General Solicitation and General Advertising Issues Presented by Electronic Filing of Form D III. ELECTRONIC FILING PROCEDURE A. Mechanics B. Database Capabilities of Electronic Form D Repository C. System Implementation IV. PAPERWORK REDUCTION ACT ANALYSIS V. COST-BENEFIT ANALYSIS VI. CONSIDERATION OF IMPACT ON COMPETITION AND PROMOTION OF EFFICIENCY, COMPETITION AND CAPITAL FORMATION VII. FINAL REGULATORY FLEXIBILITY ACT ANALYSIS VIII. STATUTORY BASIS AND TEXT OF AMENDMENTSovinfo.gov/content/pkg/COMPS-1879/pdf/COMPS-1879.pdf
Zachry Wood <zachrywood10@gmail.com> wrote: Amendments to Form D Content Requirements 1. Basic Identifying and Contact Information 2. Additional Information About Issuer 3. Identification of Claimed Exemptions and Exclusions 4. Indication of Type of Filing a. General Requirements b. Amendment of Previously Filed Form D 5. Information About Offering 6. Signature and Submission B. Electronic Filing of Form D C. General Solicitation and General Advertising Issues Presented by Electronic Filing of Form D III. ELECTRONIC FILING PROCEDURE A. Mechanics B. Database Capabilities of Electronic Form D Repository C. System Implementation IV. PAPERWORK REDUCTION ACT ANALYSIS V. COST-BENEFIT ANALYSIS VI. CONSIDERATION OF IMPACT ON COMPETITION AND PROMOTION OF EFFICIENCY, COMPETITION AND CAPITAL FORMATION VII. FINAL REGULATORY FLEXIBILITY ACT ANALYSIS VIII. STATUTORY BASIS AND TEXT OF AMENDMENTSovinfo.gov/content/pkg/COMPS-1879/pdf/COMPS-1879.pdf
