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 [email protected]: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 [email protected]: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 [email protected]: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. 🤔

[stefanzweifel]

I'm closing this issue for now, as we never really could figure out, why the workflow runs sporadicly fail.
We also didn't get any new reports of this issue in the last 6 months.