🚀 Automatically deploy your project to GitHub Pages using GitHub Actions. This action can be configured to push your production-ready code into any branch you'd like.
Go to file
James Ives 442182742b
[Release] Version 4 (#589)
* Stop checking out workspace (#515)

* Stop checking out base branch before deployment, drop option.

* Don't check out default branch, as we don't check out base branch, drop option.

* Don't stash/unstash as we don't update the workdir, drop preserve option.

* Don't init the workspace

* Only fetch the remote branch if it exists, only with depth 1.

* Rely on previous checkouts to have handled lfs files correctly, drop option.

* Update README, action.yml, integration tests

* Set up eslint for test files. (#517)

* Add DRY_RUN option, passing --dry-run to git push. (#526)

See #499 for the proposal.

* Simplifies Token Setup (#530)

* Token simplification

* Access Token / Github Token -> Token

* Oops

* Typos

* Update README.md

* Update README.md

* Update action.yml

Co-authored-by: Axel Hecht <axel@pike.org>

* Update README.md

Co-authored-by: Axel Hecht <axel@pike.org>

* Update README.md

Co-authored-by: Axel Hecht <axel@pike.org>

* Adjust codeql action to latest recommendations (#540)

Also, add the dev and release branches, and drop master.

* Add workflow to update build and node_modules on release branches (#541)

* Stores username/email in secrets

* Removing stale bot integration

* Test current code base as an integration test for PRs and pushes (#505)

* Add a build step to create lib and node_modules artifact

* Run integration test with built dist and current SHA as base

For pull requests, the github.sha is the sha of the merge to the
target branch, not the head of the PR. Special case that.

* Use v2 checkout, and DRY_RUN for the integration test.

I also made the branches more generic, as there are now more of them.

* Fix #536, don't push at all on dryRun

Also add tests for dryRun and singleCommit and generateBranch
code flows.

* Try to fix dryRun on new remote branches, refactor fetch

* Try to fix dryRun, only fetch if origin branch exists

* Refactor worktree setup to include branch generation and setup for singleCommit

This is a continuation of the no-checkout work, and sadly suggested pretty
intensive changes.

* Set up git config to fix tests, also make debugging easier

* Add matrix for existing and non-existing branch

* Add matrix for singleCommit and not

* Drop GITHUB_TOKEN, add DRY_RUN to action.yml

* When deploying existing branch, add a modifcation and deploy again

* Force branch checkout to work in redeployment scenarios

* Make singleCommit easier to see in job descriptions

* Review comments

* Add a test-only property to action to test code paths with remote branch.

* Introduce TestFlag enum to signal different test scenarios to unit tests

* Fix util.test.ts

* Update worktree.ts

* Fix a few nits in tests and automation. Don't try to wordcount ls-rem… (#546)

* Fix a few nits in tests and automation. Don't try to wordcount ls-remote.

Nits in tests are around undoing changes made to the environment,
and to not modify the checkout.

* Describe suite with empty SHA

* Lowercase Inputs (#547)

* Lowercases inputs

* Adjusts workflow tests and deployment_status

* Use multi-line string for clean-exclude patterns. (#553)

As this change is subtle, I'm taking the opportunity to change
the underscore for the hyphen, which makes it less likely that
users of this action will just pass in an old json array.

* Hyphenate inputs and outputs, add step output, fix #558 (#559)

* Hyphenate inputs and outputs, add step output, fix #558

I've also tried to make the clean docs a bit clearer, and consistent
about clean being on my default. Still not totally happy with the intro
of the docs there, though.

* Add testing of step outputs to build integration tests

* Security Docs

* Integration tests

* Revert "Integration tests"

This reverts commit 639ff537d5.

* Native SSH Key Support (#569)

* SSH Key Support 🔑

* Update ssh.ts

* Update src/ssh.ts

Co-authored-by: Axel Hecht <axel@pike.org>

* README fixes/etc

* Unit Tests & README

* ssh key

* Update README.md

* Update ssh.test.ts

* Update ssh.test.ts

* Update ssh.test.ts

* Update ssh.test.ts

* Update ssh.test.ts

* Update ssh.test.ts

* Update integration.yml

Co-authored-by: Axel Hecht <axel@pike.org>

* Deployment Issues (#583)

* Update git.ts

* Tests

* Update git.ts

* Formatting

* Update src/git.ts

Co-authored-by: Axel Hecht <axel@pike.org>

* TestFlag

* Logging

* Update git.ts

Co-authored-by: Axel Hecht <axel@pike.org>

* Codespace Support (#584)

* Add files via upload

* Update README.md

* Add files via upload

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* SSH Issues (#588)

* Unsets Persisted Credentials (#587)

* Persist

* Config Setup/Tests

* Assets

* Update git.ts

* Spacing

* Update integration.yml

* Update README.md

Co-authored-by: Axel Hecht <axel@pike.org>
2021-02-05 22:05:18 -05:00
__tests__ [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
.devcontainer [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
.github [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
assets [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
integration Version 3 (#44) 2019-11-19 10:06:27 -05:00
src [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
.eslintrc.json [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
.gitignore Changes to CNAME and nojekyll files (#362) 2020-07-13 12:52:45 -04:00
.nvmrc Update Node from 10 to 12 (#442) 2020-10-02 11:12:21 -04:00
.prettierrc.json Prettier file 2020-03-05 08:19:45 -05:00
action.yml [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
CODE_OF_CONDUCT.md Code of Conduct 2019-11-19 10:47:53 -05:00
CONTRIBUTING.md Update CONTRIBUTING.md 2020-11-18 07:30:52 -05:00
jest.config.js Formatting 2020-03-21 17:10:30 -04:00
LICENSE License Upgrades 2020-01-15 11:20:29 -05:00
package.json [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
README.md [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
SECURITY.md [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
tsconfig.json Version 3 (#44) 2019-11-19 10:06:27 -05:00
tsconfig.lint.json [Release] Version 4 (#589) 2021-02-05 22:05:18 -05:00
yarn.lock Bump @types/node from 14.14.22 to 14.14.25 (#585) 2021-02-04 07:57:46 -05:00

GitHub Pages Deploy Action 🚀

Unit test status badge Integration test status badge Code coverage status badge Release version badge Github marketplace badge

This GitHub Action will automatically deploy your project to GitHub Pages. It can be configured to push your production-ready code into any branch you'd like, including gh-pages and docs. It can also handle cross repository deployments too.

Getting Started ✈️

You can include the action in your workflow to trigger on any event that GitHub actions supports. If the remote branch that you wish to deploy to doesn't already exist the action will create it for you. Your workflow will also need to include the actions/checkout step before this workflow runs in order for the deployment to work.

You can view an example of this below.

name: Build and Deploy
on: [push]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v2.3.1

      - name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
        run: |
          npm install
          npm run build          

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@4.0.0
        with:
          branch: gh-pages # The branch the action should deploy to.
          folder: build # The folder the action should deploy.

If you'd like to make it so the workflow only triggers on push events to specific branches then you can modify the on section.

on:
  push:
    branches:
      - master

It's recommended that you use Dependabot to keep your workflow up-to-date. You can find the latest tagged version on the GitHub Marketplace or on the releases page.

Install as a Node Module 📦

If you'd like to use the functionality provided by this action in your own action you can install it using yarn or npm by running the following commands. It's available on both the npm and GitHub registry.

yarn add @jamesives/github-pages-deploy-action
npm install @jamesives/github-pages-deploy-action

It can then be imported into your project like so.

import run from "github-pages-deploy-action";

Calling the functions directly will require you to pass in an object containing the variables found in the configuration section, you'll also need to provide a workspace with a path to your project.

import run from "github-pages-deploy-action";

run({
  token: process.env["ACCESS_TOKEN"],
  branch: "gh-pages",
  folder: "build",
  repositoryName: "JamesIves/github-pages-deploy-action",
  silent: true,
  workspace: "src/project/location",
});

For more information regarding the action interface please click here.

Configuration 📁

The with portion of the workflow must be configured before the action will work. You can add these in the with section found in the examples above. Any secrets must be referenced using the bracket syntax and stored in the GitHub repository's Settings/Secrets menu. You can learn more about setting environment variables with GitHub actions here.

Required Setup

The following options must be configured in order to make a deployment.

Key Value Information Type Required
branch This is the branch you wish to deploy to, for example gh-pages or docs. with Yes
folder The folder in your repository that you want to deploy. If your build script compiles into a directory named build you'd put it here. If you wish to deploy the root directory you can place a . here. You can also utilize absolute file paths by appending ~ to your folder path. with Yes

By default the action does not need any token configuration and uses the provided repository scoped GitHub token to make the deployment. If you require more customization you can modify the deployment type using the following options.

Key Value Information Type Required
token This option defaults to the repository scoped GitHub Token. However if you need more permissions for things such as deploying to another repository, you can add a Personal Access Token (PAT) here. This should be stored in the secrets / with menu as a secret. We reccomend using a service account with the least permissions neccersary and recommend when generating a new PAT that you select the least permission scopes neccersary. Learn more about creating and using encrypted secrets here. with No
ssh-key You can configure the action to deploy using SSH by setting this option to a private SSH key stored as a secret. It can also be set to true to use an existing SSH client configuration. For more detailed information on how to add your public/private ssh key pair please refer to the Using a Deploy Key section of this README. with No

Optional Choices

Key Value Information Type Required
git-config-name Allows you to customize the name that is attached to the git config which is used when pushing the deployment commits. If this is not included it will use the name in the GitHub context, followed by the name of the action. with No
git-config-email Allows you to customize the email that is attached to the git config which is used when pushing the deployment commits. If this is not included it will use the email in the GitHub context, followed by a generic noreply GitHub email. with No
repository-name Allows you to specify a different repository path so long as you have permissions to push to it. This should be formatted like so: JamesIves/github-pages-deploy-action. You'll need to use a PAT in the token input for this configuration option to work properly. with No
target-folder If you'd like to push the contents of the deployment folder into a specific directory on the deployment branch you can specify it here. with No
commit-message If you need to customize the commit message for an integration you can do so. with No
clean If your project generates hashed files on build you can use this option to automatically delete them from the target folder on the deployment branch with each deploy. This option is turned on by default, and can be toggled off by setting it to false. with No
clean-exclude If you need to use clean but you'd like to preserve certain files or folders you can use this option. This should contain each pattern as a single line in a multiline string. with No
dry-run Do not actually push back, but use --dry-run on git push invocations insead. with No
single-commit This option can be toggled to true if you'd prefer to have a single commit on the deployment branch instead of maintaining the full history. Using this option will also cause any existing history to be wiped from the deployment branch. with No
silent Silences the action output preventing it from displaying git messages. with No
workspace This should point to where your project lives on the virtual machine. The GitHub Actions environment will set this for you. It is only necessary to set this variable if you're using the node module. with No

With the action correctly configured you should see the workflow trigger the deployment under the configured conditions.

Deployment Status

The action will export an environment variable called deployment_status that you can use in your workflow to determine if the deployment was successful or not. You can find an explanation of each status type below.

Status Description
success The success status indicates that the action was able to successfully deploy to the branch.
failed The failed status indicates that the action encountered an error while trying to deploy.
skipped The skipped status indicates that the action exited early as there was nothing new to deploy.

This value is also set as a step output as deployment-status.


Using an SSH Deploy Key 🔑

If you'd prefer to use an SSH deploy key as opposed to a token you must first generate a new SSH key by running the following terminal command, replacing the email with one connected to your GitHub account.

ssh-keygen -t rsa -m pem -b 4096 -C "youremailhere@example.com" -N ""

Once you've generated the key pair you must add the contents of the public key within your repository's deploy keys menu. You can find this option by going to Settings > Deploy Keys, you can name the public key whatever you want, but you do need to give it write access. Afterwards add the contents of the private key to the Settings > Secrets menu as DEPLOY_KEY.

With this configured you can then set the ssh-key part of the action to your private key stored as a secret.

- name: Deploy 🚀
  uses: JamesIves/github-pages-deploy-action@4.0.0
  with:
    branch: gh-pages
    folder: site
    ssh-key: ${{ secrets.DEPLOY_KEY }}
You can view a full example of this here.

name: Build and Deploy
on:
  push:
    branches:
      - master
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v2.3.1

      - name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
        run: |
          npm install
          npm run build          

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@4.0.0
        with:
          branch: gh-pages
          folder: build
          clean: true
          clean-exclude: |
            special-file.txt
            some/*.txt            
          ssh-key: ${{ secrets.DEPLOY_KEY }}

Alternatively if you've already configured the SSH client within a previous step you can set the ssh-key option to true to allow it to deploy using an existing SSH client. Instead of adjusting the client configuration it will simply switch to using GitHub's SSH endpoints.


Operating System Support 💿

This action is primarily developed using Ubuntu. In your workflow job configuration it's recommended to set the runs-on property to ubuntu-latest.

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

If you're using an operating system such as Windows you can workaround this using artifacts. In your workflow configuration you can utilize the actions/upload-artifact and actions/download-artifact actions to move your project built on a Windows job to a secondary job that will handle the deployment.

You can view an example of this pattern here.

name: Build and Deploy
on: [push]
jobs:
  build:
    runs-on: windows-latest # The first job utilizes windows-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v2.3.1

      - name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
        run: |
          npm install
          npm run build          

      - name: Upload Artifacts 🔺 # The project is then uploaded as an artifact named 'site'.
        uses: actions/upload-artifact@v1
        with:
          name: site
          path: build

  deploy:
    needs: [build] # The second job must depend on the first one to complete before running, and uses ubuntu-latest instead of windows.
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v2.3.1

      - name: Download Artifacts 🔻 # The built project is downloaded into the 'site' folder.
        uses: actions/download-artifact@v1
        with:
          name: site

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@4.0.0
        with:
          token: ${{ secrets.ACCESS_TOKEN }}
          branch: gh-pages
          folder: "site" # The deployment folder should match the name of the artifact. Even though our project builds into the 'build' folder the artifact name of 'site' must be placed here.


Using a Container 🚢

If you use a container in your workflow you may need to run an additional step to install rsync as this action depends on it. You can view an example of this below.

- name: Install rsync 📚
  run: |
    apt-get update && apt-get install -y rsync    

- name: Deploy 🚀
  uses: JamesIves/github-pages-deploy-action@4.0.0

Additional Build Files 📁

If you're using a custom domain and require a CNAME file, or if you require the use of a .nojekyll file, you can safely commit these files directly into deployment branch without them being overridden after each deployment, additionally you can include these files in your deployment folder to update them. If you need to add additional files to the deployment that should be ignored by the build clean-up steps you can utilize the clean-exclude option.

Click here to view an exmaple of this.

name: Build and Deploy
on:
  push:
    branches:
      - master
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v2.3.1

      - name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
        run: |
          npm install
          npm run build          

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@4.0.0
        with:
          branch: gh-pages
          folder: build
          clean: true
          clean-exclude: |
            special-file.txt
            some/*.txt            

If you wish to remove these files you must go into the deployment branch directly to remove them. This is to prevent accidental changes in your deployment script from creating breaking changes.


Support 💖

This project would not be possible without all of our fantastic contributors. The project logo was created by Paganini.

If you'd like to support the maintenance and upkeep of this project you can donate via GitHub Sponsors. This project is distributed under the MIT license.