Sporadic 403 Errors

[ax3l]

git-auto-commit Version

v4

Machine Type

Ubuntu (eg. ubuntu-latest)

Bug description

Hi,

I am using the latest recommended permission settings to update pull requests.

Sporadically, even though nothing changed, I see errors of this kind:

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

Steps to reproduce

Last run was in:
https://github.com/AMReX-Codes/pyamrex/actions/runs/6398796490/job/17370800918

My action file is:
https://github.com/AMReX-Codes/pyamrex/blob/9a2614a651b3133091bcf592a92e850cf61b621f/.github/workflows/stubs.yml

Tried solutions

I do not use a PAT yet.

I think the solution might be related to switching from https://github.com/user/repo to git@github.com:user/repo.git style repos to avoid the HTTPS auth?

Example Workflow

My action file is:
https://github.com/AMReX-Codes/pyamrex/blob/9a2614a651b3133091bcf592a92e850cf61b621f/.github/workflows/stubs.yml

Relevant log output

log.txt

[stefanzweifel]

Thanks for raising this issue.

The workflow log shows "Permission denied".

remote: Permission to ax3l/pyamrex.git denied to github-actions[bot].

Do you have set up any special settings in the repository? Protected branches? Special workflow permissions (Settings → Actions → General → Workflow permissions)?

I think this might also be related to the pull_request event trigger. The runs triggered by pull_request fail more often than for push.

But some older runs fail due to the usage of protected branches: log

For that, you will need to use a PAT. See docs.

I think the solution might be related to switching from https://github.com/user/repo to git@github.com:user/repo.git style repos to avoid the HTTPS auth?

git-auto-commit doesn't deal with git authentication at all. actions/checkout is responsible for this.
But I currently can't find a setting to change this in actions/checkout.

[ax3l]

Thank you, @stefanzweifel!

Do you have set up any special settings in the repository? Protected branches? Special workflow permissions (Settings → Actions → General → Workflow permissions)?

The repo in question is a fork without any branch protections applied to it. Also, "Edit from Maintainers" is (default) checked on for the PR. Default workflow permissions (read and write).

I think this might also be related to the pull_request event trigger. The runs triggered by pull_request fail more often than for push.

Yes, I see this sporadically for my PRs.

But some older runs fail due to the usage of protected branches: log

Ah yes, that are pushes, I need to disable these or add a PAT. Generally, I try to update pre-merge in PRs.

I think the solution might be related to switching from https://github.com/user/repo to git@github.com:user/repo.git style repos to avoid the HTTPS auth?

git-auto-commit doesn't deal with git authentication at all. actions/checkout is responsible for this.
But I currently can't find a setting to change this in actions/checkout.

Really interesting. Yes I wonder if this causes it - could the auth time out if there is too much time spend between checkout and push?

[stefanzweifel]

The repo in question is a fork without any branch protections applied to it

Ah! That might be the clue.
If a pull request is opened from a fork and the workflow should run in the base repostiory and push something back to Github, you need to use pull_request_target as the trigger; instead of pull_request.

We have docs for this here: https://github.com/stefanzweifel/git-auto-commit-action#use-in-forks-from-public-repositories

It's also important that you check out the right repository using repository: ${{ github.event.pull_request.head.repo.full_name }}.

The bad part here is the step may no longer work if the workflow is triggered using pull_request.
I've mentioned this solution in another issue as well (#278 (comment)) and mentioned that I'm not sure if you can keep both triggers in your workflow. That was in January.
Since then I didn't have the time and head space to take a closer look at this. Pushing this up my todo list so I can close these issues by the end of the year.

---

When I look closer at a workflow run, it becomes clearer what is failing.

For example this workflow run.
The run is executed in the AMReX-Codes/pyamrex repository but tries to push to your fork on ax3l/pyamrex.
As these repositories belong to different users/orgs, this causes permission issues.

[ax3l]

Now I see the error again here:
AMReX-Codes/pyamrex#204

But only took 4min between checkout and push.

[ax3l]

you need to use pull_request_target as the trigger; instead of pull_request.

Oh wow, I did not know a pull_request_target exists in GH actions o.0 Now figuring out the difference between

• https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request and
• https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target

Interesting, aha.

The run is executed in the AMReX-Codes/pyamrex repository but tries to push to your fork on ax3l/pyamrex.
As these repositories belong to different users/orgs, this causes permission issues.

I'll try pull_request_target: AMReX-Codes/pyamrex@6ef5591 :)

[RLRabinowitz]

Hey @stefanzweifel

I'm seeing a similar behaviour. Sporadic 403 errors, re-running the workflow usually fixes the issue.

Failing run - action. The run after it works - action

The action file is https://github.com/opentofu/registry-stable/blob/f2177346eafbc7fcdee2b35d304666665650278f/.github/workflows/bump-versions.yml

[stefanzweifel]

Thanks for reporting @RLRabinowitz.
Personally currently can't see any issue in the usage of the Action.
IMHO I think this seems to be a general issue of GitHubs availability. In the last few weeks I regularly encountered API requests or operations in the web UI to fail randomly. A re-run of the API request usually worked. 🤔