GitHub Pages Deploy Action :rocket:

Automatically deploy your project to GitHub Pages with GitHub Actions. This action 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 and works with GitHub Enterprise too.

Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here. 💖

Getting Started :airplane:

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. If you intend to make multiple deployments in quick succession you may need to leverage the concurrency parameter in your workflow to prevent overlaps.

You can view an example of this below.

``yml
name: Build and Deploy
on: [push]
permissions:
contents: write
jobs:
build-and-deploy:
concurrency: ci-${{ github.ref }} # Recommended if you intend to make multiple deployments in quick succession.
runs-on: ubuntu-latest
steps:
- name: Checkout 🛎️
uses: actions/checkout@v4

- 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 ci
npm run build

- name: Deploy 🚀
uses: JamesIves/github-pages-deploy-action@v4
with:
folder: build # The folder the action should deploy.
`

> [!NOTE]
> You must configure your repository to deploy from the branch you push to. To do this, go to your repository settings, click on Pages, and choose Deploy from a Branch from the Source dropdown. From there select the branch you supplied to the action. In most cases this will be gh-pages as that's the default.

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.

`yml
on:
push:
branches:
- main
`

> [!WARNING]
> If you do not supply the action with an access token or an SSH key, you must access your repositories settings and provide Read and Write Permissions to the provided GITHUB_TOKEN, otherwise you'll potentially run into permission issues. Alternatively you can set the following in your workflow file to grant the action the permissions it needs.

`yml
permissions:
contents: write
`

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 |
| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | -------- |
| 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 prepending ~ to your folder path. Note that any files/folders matching .gitignore entries will not be deployed. Some tools auto-generate a .gitignore file for build output. | 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 recommend using a service account with the least permissions necessary and recommend when generating a new PAT that you select the least permission scopes necessary. 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 |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | -------- |
| branch | This is the branch you wish to deploy to, for example, gh-pages or docs. Defaults to gh-pages. | with | No |
| 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. You can include <> for the value if you wish to omit this field altogether and push the commits without an 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 | You can use this option to delete files from your deployment destination that no longer exist in your deployment source. One use case is if your project generates hashed files that vary from build to build. Using clean will not affect .git, .github, or .ssh directories. 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 instead. | 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 |
| force | Force-push new deployments to overwrite the previous version; otherwise, attempt to rebase new deployments onto any existing ones. This option is turned on by default and can be toggled off by setting it to false, which may be useful if there are multiple deployments in a single branch. | with | No |
| attempt-limit | How many rebase attempts to make before suspending the job. This option defaults to 3 and may be useful to increase when there are multiple deployments in a single branch. | with | No |
| silent | Silences the action output preventing it from displaying git messages. | with | No |
| tag | Add a tag to the commit. Only works when dry-run is not used. | 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.

---

$3

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.

`bash
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.

`yml
- name: Deploy 🚀
uses: JamesIves/github-pages-deploy-action@v4
with:
folder: site
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.

---

$3

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

`yml
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.

---

$3

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.

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

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

---

$3

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 the 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.

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.