Permission to denied error when deploying

[jhlegarreta]

Hi,
thanks for developing and maintaining this tool.

I am trying to use it for a repository that I contribute to. So far, my effort has been unsuccessful. I am getting an

remote: Permission to SlicerDMRI/SlicerDMRI.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/SlicerDMRI/SlicerDMRI.git/': The requested URL returned error: 403

error at the moment where the deployment should take place: https://github.com/SlicerDMRI/SlicerDMRI/actions/runs/6685911043/job/18164701923?pr=195#step:2:787

I have seen that there are a few discussions reporting this behavior, but the solutions suggested seem not to work in this case: I have granted write permissions to the workflow, actions do have write permissions in the repository settings, and the GitHub pages Build and deployment is configured to deploy from the gh-pages branch; I have also tried setting it to GitHub Actions with the same result.

I am using the doxygen-github-pages-action, which is in turn using this action. I have asked there as well: the only hypothesis being that I am trying to see the effect of the action from a fork.

Is there as solution to this? What am I missing?

Thanks.

[jhlegarreta]

the only hypothesis being that I am trying to see the effect of the action from a fork.

Gave this a try (directly pushing the workflow file to master), and did not work: it showed the README page.

The gh-pages branch contained the right content, with the index.html being the landing page for the Doxygen documentation: https://github.com/jhlegarreta/SlicerDMRI/tree/gh-pages

In the Settings of my fork, GitHub Pages/Build and deployment I had tried both options GitHub Actions and Deploy from a Branch (the branch being gh-pages) with the same result.

Just for the sake of trying it, I later created directly in GitHub another GHA workflow file this time using:

on:
  push:
    branches:
      - main

in the workflow file (using main was an oversight on my side -the repository uses master; I presume the deployment took place as I manually run the action), and it got deployed correctly (with poor documentation from the package for unrelated reasons):

So it looks there is some issue with the action being used from a fork or the events triggering the action.