Github action not triggering gh-pages upon push

Thanks, now we have a pretty straightforward answer about that issue :slight_smile: . Basically it’s not a bug but a design decision.

On the other hand it is kind of a usability issue. This behavior makes it impossible to have a “copy and paste” workflow configuration or a “fork and publish” repository that will just build a repository and publish it to Github’s web hosting without complex additional configuration. (Like it’s possible to do so with both Gitlab and Bitbucket as example.)

Is there any chance this usability problem could be considered by the dev team to create some kind of specific exception for static web content publishing?


It’s something that we should give some more thought to, but we need to weigh that with the more common usability concern of push triggers within push triggers.  Given this common workflow trigger:

on: [push, pull_request]
run: build_site && git push origin gh-pages

If you were to update a gh-pages branch in this workflow, you’d get into an infinite loop - your first workflow would push the gh-pages branch, which would trigger this workflow, ad infinitum.

Obviously you could construct a less naive workflow that filters based on branches, or only pushes when changes are detected, etc.  (Perhaps this will coincidentally no-op because there’s no changes in the source branch.)  But it’s a concern and that’s why we’re limitation workflow execution in this way from the token.

I’ve logged an issue to give this particular workflow consideration some more thought.  We should improve the guidance, at least, even if we don’t relax the token restrictions.


Mea culpa - I was wrong about the reason that this wasn’t working.  In fact, there was an issue occurring between GitHub Actions and GitHub Pages.  We made some changes to GitHub Pages that we think should have mitigated this isssue.

Here’s an example that should work:

# pushes using the user that kicked off the action. Requires `jq` in the builder
git config $(jq .pusher.username $GITHUB_PAYLOAD)
git config $(jq $GITHUB_PAYLOAD)

git add --all
git commit -m "Publish to gh-pages branch"
git remote add pages https://x-access-token:$
git push pages gh-pages -f

@ivoputzer and @nicolas-van could you try your workflow again and let me know if it still isn’t working?


To visitors, (2020-05-03)

This problem has been already fixed about 3 months ago.

Now, the GITHUB_TOKEN works well for deploying to GitHub Pages on public repositories and private repositories.

peaceiris/actions-gh-pages: GitHub Actions for GitHub Pages 

- uses: peaceiris/actions-gh-pages@v3
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: ./public

Old message:


I tried it using peaceiris/actions-gh-pages but GitHub Pages building does not start. Action log

1 Like

Thanks @peaceiris , investigating further.


Hi @ethomson 

I found it. The following step works well for only my private repo. For private repositories, GITHUB_TOKEN works well but public repositories failed. Is this an expected behavior?

- name: Deploy
  uses: peaceiris/actions-gh-pages@v2.4.0
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    PUBLISH_BRANCH: gh-pages
    PUBLISH_DIR: ./public

Issues #9 | peaceiris/actions-gh-pages


I have a similar workflow/action using GITHUB_TOKEN in a priviate repository. And pushes to gh-pages will be picked up by Github Pages without a problem—but the repo has to be private. When I make it public, the environment does not seem to get updated.


It would be really handy if GitHub Actions can trigger GitHub Pages build using GITHUB_TOKEN.

You can do the “workaround” using SSH deploy keys, but it’s adding complexity and I’m not sure if this can be automated if you have many GitHub repos.

When you use GITHUB_TOKEN there is nothing to configure - you just create “GitHub Action” and you are done.

Thank you…


It seems to have been established that it is a bug by now. The fact it works as expected with private repositories, like reported by @bryanschuetz and tested by @peaceiris , but not with public repositories is an inconsistency in itself that can not be considered in another way than a bug.

Let’s just hope that the Github team will solve it one day or another ^^


I can confirm that a Private repository does “fix” the issue. It’s still a bit of a weird scenario and the error message really doesn’t help troubleshooting the issue :slight_smile:


I ran into this issue too.

While I was developing the action in private repository, it worked fine. But once I published it, deploying gh-pages started to fail.


Finally, GitHub Actions is going to be GA today. Thank you, the GitHub support team and the community. Also, I hope that this issue will be considered after Actions become stable.


As of last week I’m not even able to deloy using an access token anymore. Has something changed? I just end up with Page Build Errorr everytime. 

Edit: This was resolved by changing actions/checkout@master to actions/checkout@v1.


@ethomson Just re-iterating that this is still not working for public repositories, even after the General Availablity. You can push to the gh-pages branch with a GITHUB_TOKEN, but the push does not trigger a GitHub pages deploy.

Doing something else to trigger a deploy (like a manual empty commit) does trigger a deploy with the updated content however.


Seeing this same issue in my public repo. My action is setup on a schedule, so the ‘avoiding recursive actions’ feature should not even apply to this action. Also, I’m using checkout@v2. Action:


Also experienced this issue. Pushing to public repo with ${{ secrets.GITHUB_TOKEN }} does not trigger a successful github pages build. Manual workaround is to change the branch which github pages is to deploy for a moment and then change it back to the original branch.

- name: Deploy
      uses: peaceiris/actions-gh-pages@v2.8.0
        PUBLISH_BRANCH: master
        PUBLISH_DIR: ./public
        keepFiles: true

I modify my  configuration here , now it is success. You should add  SSH deploy key following this :

1 Like

@lovepoem, as commented in, using a deployment key is not a solution, but an (uncomfortable) workaround. The default GITHUB_TOKEN allows to push changes to a branch of the same repo (which can be ‘gh-pages’). The issue is on GitHub’s deployment feature refusing to pick the commits pushed by the bot.

Yes. Deployment key option is a current workaround better than a personal access token (PAT has too large scope). I hope that GitHub Pages build event can be triggered by GITHUB_TOKEN on a public repository. (GITHUB_TOKEN can trigger the event on a private repository.)

Even the Personal Access Token seems to not trigger the update these days.