For some reason when pushing towards `gh-pages` branch from within a `github action` the commit appears to be correctly pushed towards the branch but does not trigger github pages deployments (within environment tabs).
Do you have any advice on what i could have a look at?
The `GITHUB_TOKEN` that is provided as a part of GitHub Actions doesn't have authorization to create any successive events, such as GitHub Pages builds. So while you can push to the `gh-pages` branch using the `GITHUB_TOKEN`, it won't spawn a GitHub Pages build. You'll need to create a personal access token and supply it to your GitHub Action as a secret.
I used https://github.com/peaceiris/actions-gh-pages for a recent project because it already has a workaround for exactly this problem and seems to be actively maintained.
I hope that helps!
Thanks, now we have a pretty straightforward answer about that issue :-) . 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 user.name $(jq .pusher.username $GITHUB_PAYLOAD) git config user.email $(jq .pusher.email $GITHUB_PAYLOAD) git add --all git commit -m "Publish to gh-pages branch" git remote add pages https://x-access-token:$GITHUB_TOKEN@github.com/:owner/:repo.git git push pages gh-pages -f