Update: I had assumed that the latest main hashref would contain the fixes in v3, but for now I'll try using 068dc23 which is the v3 tag's current hashref for immutability.

I have left a comment on an issue somewhere in the past, but I couldn't find it, so I'll restate it here. Our project builds and provides build assets only when creating a release. This is to prevent the user from executing this action with a specific branch (like main). For example, if we maintain build assets in the main branch and users use this action as follows, a major release including breaking changes will break the CI workflow of the users silently.

- name: Deploy
  uses: peaceiris/actions-gh-pages@main  # Bad example!
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: ./public

In this project, a major tag (e.g. v3) is guaranteed to contain no breaking changes. But, we recommend using a tag or a commit hash for the stability of your workflows.

- name: Deploy
  uses: peaceiris/actions-gh-pages@v3.8.0 # tag: Better (Dependabot uses this type)
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: ./public

- name: Deploy
  uses: peaceiris/actions-gh-pages@068dc23d9710f1ba62e86896f84735d869951305  # commit hash of v3.8.0: Best!
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: ./public

Our project builds and provides build assets only when creating a release.

See the next script.

This issue has been marked as inactive.

If you still encounter this or it has changed, add a comment to provide further information.

@peaceiris thanks for the reply, I also figured out after posting this that instead of taking the SHA of the latest trunk branch, I could use the SHA of a release instead to achieve the same effect while still using a SHA instead of a tag, as per GitHub Actions Security Best Practice.

Thanks for the reply here, closing.

This issue has been marked as inactive.

If you still encounter this or it has changed, add a comment to provide further information.

This issue has been LOCKED because of it being resolved!

The issue has been fixed and is therefore considered resolved.
If you still encounter this or it has changed, open a new issue instead of responding to solved ones.