Permissions error

[raquelalegre]

I am getting a permissions error that I am confused about.
This is a public repository, and from the instructions it sounds like I don't need to set up any deploy keys or ssh keys. I understand it's just the GITHUB_TOKEN that is being used behind the scenes and gets created automatically by GH Actions.

The error message says:

[...]
Switched to a new branch 'github-pages-deploy-action/grtnldvn6'
/usr/bin/git commit -m Deploying to gh-pages from @ UCL/UKCORDEX-plot-explorer-dev@2a76146fab2df470abb4af4bdc912d4badeefbfd 🚀 --quiet --no-verify
/usr/bin/git push --force ***github.com/UCL/UKCORDEX-plot-explorer-dev.git github-pages-deploy-action/grtnldvn6:gh-pages
remote: Permission to UCL/UKCORDEX-plot-explorer-dev.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/UCL/UKCORDEX-plot-explorer-dev.git/': The requested URL returned error: 403
Running post deployment cleanup jobs… 🗑️
/usr/bin/git checkout -B github-pages-deploy-action/grtnldvn6
Reset branch 'github-pages-deploy-action/grtnldvn6'
/usr/bin/chmod -R 777 github-pages-deploy-action-temp-deployment-folder
/usr/bin/git worktree remove github-pages-deploy-action-temp-deployment-folder --force
Error: The deploy step encountered an error: The process '/usr/bin/git' failed with exit code 128 ❌
Deployment failed! ❌
[...]

The complete log is in https://github.com/UCL/UKCORDEX-plot-explorer-dev/runs/4868866705?check_suite_focus=true

This is my workflow:

name: Deploy React Application

# Controls when the action will run. 
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ development ]
  pull_request:
    branches: [ development ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  build_test:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x] # We will deploy with only one version of node  

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}    
      - name: npm ci and build
        run: |
          npm ci
          npm run build --if-present
      - name: Deploy 🚀
        uses: JamesIves/[email protected]
        with:
          branch: gh-pages # The branch the action should deploy to.
          folder: build # The folder the action should deploy.

[JamesIves]

Morning,

Are you running this workflow within an organization? If so it might be necessary for you to provide a token parameter with a PAT from a service account that has push permissions to that repository. Sometimes the built-in token provided by the GitHub workflow runner doesn't have adequate permissions and this error will sometimes throw. The README has some additional details on how you can set this up.

 - name: Deploy 🚀
   uses: JamesIves/[email protected]
   with:
      branch: gh-pages
      folder: build
      token: ${{ secrets.PAT }}

[raquelalegre]

Thank you for your quick answer! This makes sense, as everything worked when I tried the website on my own user organisation, but it didn't once I tried it in the work one.
I'm still confused about how to proceed. Do I need to create a PAT in the repository secrets, or at the organisation level? What's your GH action validating that token value against?

[raquelalegre]

Ok, so my last question didn't make sense because I didn't quite get how to configure a PAT 0:)
All understood now!

Also, something I want to try is to specify permissions for the GITHUB_TOKEN explicitly in the workflow. I'll test both ways (PAT and explicitly permissions in workflow) and report how it went in case it helps someone else in the future.

[raquelalegre]

With the PAT token I got a different error:

https://github.com/UCL/UKCORDEX-plot-explorer-dev/runs/4881033071?check_suite_focus=true#step:5:49

[...]
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/UCL/UKCORDEX-plot-explorer-dev.git/'
[...]

[raquelalegre]

And the explicit setup of write permissions for the job also didn't work. I've also tried giving more permissions to the PAT token, but still get the same error about username/password. I'm blocked :(

[raquelalegre]

Using ssh-key also gave me the older error message:

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

[JamesIves]

The personal access token that you generate needs to have adequate read/write permissions over that specific repository. The correct process for this would be to:

• Create a new user, or assign an existing user read/write permissions over the repository you want to deploy to within that organization, so they personally can push to it.
• Generate a personal access token from that users account that provides organization permission levels. The reason I mentioned create a new user is so you're not providing the bot more permissions than it needs, but in some cases this may not be necessary/possible.
• Assign the token parameter in the github-pages-deploy-action step via a repository level secret.

If you're getting invalid username/password it means that your PAT isn't scoped correctly and it's hitting a permission error, or it's not being assigned correctly. You can think of this as extending personal permissions to the github-actions bot so it can make commits on your behalf. The steps are similar but not quite the exact same for the ssh-key parameter, you can learn how to do that here.

Can you also provide your workflow examples for the failed runs above? Additionally can you verify that you added the generated PAT to the Settings > Secrets menu within the org you're configuring the workflow on?

[JamesIves]

Taking another look at your workflow at the top of this thread it looks like there's no token parameter set. You need to have something like this configured with ${{ secrets.PAT }} pointing to the secret you named in your repository secrets menu:

 - name: Deploy 🚀
   uses: JamesIves/[email protected]
   with:
      branch: gh-pages
      folder: build
      token: ${{ secrets.PAT }}

The logging here isn't very good (and will be improved in 4.3.0) but you can see the action logs Deploying using …… 🔑 which indicates it doesn't have a valid key setup. It would normally say SSH Key or Deploy Key depending on what is configured.

[raquelalegre]

Found the problem, all credit to my colleague @ageorgou :)

Secrets are not passed to workflows that are triggered by a pull request from a fork. Learn more.

Apparently even the default GITHUB_TOKEN only has read permissions if used by a fork.

That's the problem, I created the new workflow in a fork of the website repo, and it was the PR where I was trying to merge my changes to the main repo that wouldn't get permissions to access. I merged that repo, then tried from a branch from within the main repo and it all worked via GITHUB_TOKEN. No need for any further permissions.

For someone else who runs into this problem and needs to keep on pushing from a fork, a possible solution is to try triggering it on pull_request_target event. This is basically the same as pull_request, but it gives access to secrets and also the GITHUB_TOKEN has write permissions. I haven't tested this though, so I'm not 100% sure it'll work.

[firefoxic]

@raquelalegre Thank you very much for this suggestion!

But just replacing pull_request with pull_request_target was not enough. The thing is that these two events have different ref: the first one contains a reference to the pull request branch, and the second one - to the main branch. This leads to the fact that when pull_request_target with the default ref the project is built from the main branch.

This is easily fixed by specifying ref in the Checkout action to a branch with a dynamic pull request number. Live example:

• finished workflow: https://github.com/firefoxic/test-actions/blob/main/.github/workflows/predeploy-on-pull-request.yaml
• project main page published from the main branch: https://firefoxic.github.io/test-actions/
• project main page published from the branch of the pull request number 6: https://firefoxic.github.io/test-actions/6/

Perhaps because of insecurely open access to secrets in production code, this is not worth using. But I have nothing to be afraid of in repositories for students, and it works exactly as it should - it's convenient to check assignments completed by students.