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] jobs: publish: steps: 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.