mirror of
https://github.com/JamesIves/github-pages-deploy-action.git
synced 2023-12-15 20:03:39 +08:00
95f8a2cd05
* Return early from dry run Determining whether to create a merge commit would elicit a nested conditional, which could be hard to parse for a human reader. This is avoided by returning early as soon as possible for a dry run. This also resolves the erroneous 'changes committed' message when no changes were actually committed because of the dry run. A message specific to dry-run is logged instead. * Add force parameter to action interface Existing behaviour is equivalent to force=true, so the default value is true. * Implement pull+rebase procedure * Declare force parameter in action * Detect both rejection syntaxes * Return both stdout and stderr from execute * Ignore non-zero exit status on push * Remove unnecessary error catch * Fetch and rebase in separate steps * Explicitly bind incoming branch I think the fetch will update the origin/gh-pages branch but not the gh-pages branch, despite requesting gh-pages. This means that when I later attempt to rebase the temp branch on top of the gh-pages branch, there will be nothing to do, because that's already where it is. * Implement attempt limit I don't expect this to ever require more than one attempt in production, but in theory it's possible that this procedure could loop forever. We would need to keep fetching and rebasing if changes keep being added to the remote. In practice, I believe this would only happen if there are lots of workflows simultaneously deploying to the same branch, all using this action. In this case only one would be able to secure a lock at a time, leading to the total number of attempts being equal to the number of simultaneous deployments, assuming each deployment makes each attempt at the exact same time. The limit may need to be increased or even be configurable, but 3 should cover most uses. * Update tests for execute output split * Document 'force' parameter * Create integration test for rebase procedure This test is composed of 3 jobs. The first two jobs run simultaneously, and as such both depend on the previous integration test only. The final job cleans up afterwards, and depends on both of the prior jobs. The two jobs are identical except that they both create a temporary file in a different location. This is to ensure that they conflict. Correctly resolving this conflict by rebasing one deployment over the other, resulting in a deployment containing both files, indicates a successful test.
95 lines
4.7 KiB
YAML
95 lines
4.7 KiB
YAML
name: 'Deploy to GitHub Pages'
|
|
description: 'This action will handle the deployment process of your project to GitHub Pages.'
|
|
author: 'James Ives <iam@jamesiv.es>'
|
|
runs:
|
|
using: 'node12'
|
|
main: 'lib/main.js'
|
|
branding:
|
|
icon: 'git-commit'
|
|
color: 'orange'
|
|
inputs:
|
|
ssh-key:
|
|
description: >
|
|
This option allows you to define a private SSH key to be used in conjunction with a repository deployment key to deploy using SSH.
|
|
The private key should be stored in the `secrets / with` menu **as a secret**. The public should be stored in the repositories deployment
|
|
keys menu and be given write access.
|
|
|
|
Alternatively you can set this field to `true` to enable SSH endpoints for deployment without configuring the ssh client. This can be useful if you've
|
|
already setup the SSH client using another package or action in a previous step.
|
|
required: false
|
|
|
|
token:
|
|
description: >
|
|
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 neccersary
|
|
and when generating a new PAT that you select the least permission scopes required.
|
|
|
|
[Learn more about creating and using encrypted secrets here.](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)
|
|
required: false
|
|
default: ${{ github.token }}
|
|
|
|
branch:
|
|
description: 'This is the branch you wish to deploy to, for example gh-pages or docs.'
|
|
required: true
|
|
|
|
folder:
|
|
description: 'The folder in your repository that you want to deploy. If your build script compiles into a directory named build you would put it here. Folder paths cannot have a leading / or ./. If you wish to deploy the root directory you can place a . here.'
|
|
required: true
|
|
|
|
target-folder:
|
|
description: 'If you would like to push the contents of the deployment folder into a specific directory on the deployment branch you can specify it here.'
|
|
required: false
|
|
|
|
commit-message:
|
|
description: 'If you need to customize the commit message for an integration you can do so.'
|
|
required: false
|
|
|
|
clean:
|
|
description: '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 on by default and can be toggled off by setting it to false.'
|
|
required: false
|
|
default: true
|
|
|
|
clean-exclude:
|
|
description: 'If you need to use clean but you would 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.'
|
|
required: false
|
|
|
|
dry-run:
|
|
description: 'Do not actually push back, but use `--dry-run` on `git push` invocations insead.'
|
|
required: false
|
|
|
|
force:
|
|
description: 'Whether to force-push and overwrite any existing deployment. Setting this to false will attempt to rebase simultaneous deployments. This option is on by default and can be toggled off by setting it to false.'
|
|
required: false
|
|
default: true
|
|
|
|
git-config-name:
|
|
description: 'Allows you to customize the name that is attached to the GitHub 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.'
|
|
required: false
|
|
|
|
git-config-email:
|
|
description: 'Allows you to customize the email that is attached to the GitHub 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.'
|
|
required: false
|
|
|
|
repository-name:
|
|
description: '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'
|
|
required: false
|
|
|
|
workspace:
|
|
description: "This should point to where your project lives on the virtual machine. The GitHub Actions environment will set this for you. It is only neccersary to set this variable if you're using the node module."
|
|
required: false
|
|
|
|
single-commit:
|
|
description: "This option can be used if you'd prefer to have a single commit on the deployment branch instead of maintaining the full history."
|
|
required: false
|
|
|
|
silent:
|
|
description: 'Silences the action output preventing it from displaying git messages.'
|
|
required: false
|
|
|
|
outputs:
|
|
deployment-status:
|
|
description: 'The status of the deployment that indicates if the run failed or passed. Possible outputs include: success|failed|skipped'
|