git-auto-commit-action: Limitations on PRs from forks no longer apply
In the readme section “Advanced Uses” > “Use in forks from public repositories” it says that “GitHub Action has to be enabled on the forked repository.” and “the Workflow will run on the forked repository”, however this doesn’t seem to be the case. The docs for pull_request_target and this GitHub blog post suggests that the main difference pull_request_target has compared to pull_request is that it runs from the base of the PR instead of the PR merge commit, i.e., any changes to the workflow file in the PR will not take effect until merged.
An example is, this workflow file is triggered by pull_request_target, and when you open a PR from a fork (with GitHub Actions disabled) it runs within the repository where the PR is (not the fork).
And this GitHub Action is able to commit to the fork while running in the non-fork repo. It’s able to commit with the default GITHUB_TOKEN and you can checkout the PR branch at the fork repository with:
- uses: actions/checkout@v3
with:
repository: ${{ github.event.pull_request.head.repo.full_name }}
ref: ${{ github.head_ref }}
So it seems like the limitations on running in PRs from forks no longer apply! 🎉
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 19 (9 by maintainers)
Commits related to this issue
- Fix docs about using in public forks Update docs section about using the Action in public forks. Add warning about current issue when the forks lives under an organisation. Mark section about runni... — committed to stefanzweifel/git-auto-commit-action by stefanzweifel a year ago
- Add Alert about pull_request_target https://github.com/stefanzweifel/git-auto-commit-action/issues/211#issuecomment-1837270114 — committed to stefanzweifel/git-auto-commit-action by stefanzweifel 7 months ago
- Attempt to solve write access as a PR workflow from forks https://github.com/marketplace/actions/git-auto-commit#use-in-forks-from-public-repositories https://github.com/stefanzweifel/git-auto-commit-... — committed to fritx/jsonmerge by fritx 5 months ago
- Attempt to solve write access as a PR workflow from forks - part 2 https://github.com/marketplace/actions/git-auto-commit#use-in-forks-from-public-repositories https://github.com/stefanzweifel/git-aut... — committed to Jayin/jsonmerge by fritx 5 months ago
- Update README concerning pull_request_target trigger Closes #211 — committed to ViliusSutkus89/git-auto-commit-action by stefanzweifel 2 years ago
- Squashed commit of the following: commit fe1c228e1302ce65e5640a26a511c1408fa5e0be Author: Constantin Comendant <constantin@uberagent.com> Date: Thu Apr 11 14:53:29 2024 +0200 remove changelog ... — committed to vastlimits/uberAgent-config by deleted user 3 months ago
Thanks
I spent the day trying to create an autolint system to fix PRs of external contributors to my open-source repo, and tried various techniques without any good result.
https://github.com/slorber/lint-autofix-ci-demo https://github.com/slorber/lint-autofix-ci-demo/pull/1
I tried splitting the workflow 2 as suggested:
It felt quite inconvenient to pass data (git diff) between the 2 workflows using artifacts. Apparently you could also use job outputs, but didn’t try yet: https://twitter.com/yarlob/status/1735350688052342809
I also tried to implement a workflow where the linting would happen when you comment the PR, but couldn’t push to the forked branch due to permission issues: https://github.com/slorber/lint-autofix-ci-demo/blob/7f9745c1782c247cef3a313b366f52b158ff84ed/.github/workflows/lint-autofix-comment.yml
Even with the “pull_request_target” unsafe workflow, I couldn’t get it to push to my own remote branch with permissions issues: https://github.com/slorber/lint-autofix-ci-demo/blob/7f9745c1782c247cef3a313b366f52b158ff84ed/.github/workflows/lint-autofix-unsecure-test.yml https://github.com/slorber/lint-autofix-ci-demo/actions/runs/7212924277/job/19651657295?pr=1
Who has been able to push to a fork branch here, even unsafely with
pull_request_target?Does it require a PAT?
Or can the default GitHub token + bot account be enough to push to contributors branches?
EDIT: I confirm a PAT seems to be required to push to fork branches
In fact I tried to do it the other way, where the workflow runs in the forked repository instead, and I couldn’t get that to work either.
I forked the repo, enabled github actions (and all permissions), then opened a pull request, and still no workflow ran in the forked repo, only the base repo.
According to this section in the GitHub docs:
This makes me think the “Workflow should run in forked repository” of your readme isn’t right somehow…
GitHub is sure making this frustrating. All I want to do is make a commit to a pull request, whether it be to the base or to the fork, as long as it gets added to the PR. It also needs to work regardless of whether the PR is opened from a branch or a fork.
I’m having trouble getting this to work, and I believe I’m doing everything the same, except for that I’m calling the workflow from another workflow, but I believe it’s still getting the right repo and ref and all that. Here are my workflows and logs. In this case I’m trying to do a pull request from
greenelab/lwt-test:testintovincerubinetti/lab-website-template:main(I also triedmainintomain). I’m still getting the error:Both repos also have Actions enabled, and the most permissive settings:
I happen to be an admin under both organizations,
vincerubinettiandgreenelab.triggering workflow
called workflow
logs
Setup Job
Checkout branch contents
Commit updated citations
Link to run (will dissappear in the future): https://github.com/vincerubinetti/lab-website-template/actions/runs/4118566556/jobs/7111241089
Log dump
You’re totally right. That’s how this works. I’ve been too far away from the innerworkings of GitHub Actions in the last few months. 😅
And this actually also worked in my demo repository. https://github.com/stefanzweifel/git-auto-commit-action-demo-app/pull/34
Will update the README shortly with an example using
repository: ${{ github.event.pull_request.head.repo.full_name }}.The
pull_request_targettrigger only takes effect if it is present in the workflow file in the PR base branch, i.e., the workflow https://github.com/stefanzweifel/git-auto-commit-action-demo-app/blob/main/.github/workflows/format_php.yml not the PR branch. The security measure is that GitHub Actions runs the version of the workflow fromstefanzweifel/git-auto-commit-action-demo-app(main) and notwnxtrash/git-auto-commit-action-demo-app(main). So you have full control of the actions that are run and it is therefore trusted with aGITHUB_TOKENwithwritepermissions.Here’s an example of a workflow running with
writepermission even though the user who triggered it doesn’t have special repository or organisation permissions: https://github.com/sunpy/sunpy/runs/5952858318?check_suite_focus=true#step:1:14@slorber
I agree.
pull_request_targetisn’t safe, as a bad actor can steal them your secrets, if you have any. And apparently there’s no Action-only fix available.Thanks for the link for autofix.ci. To make things clearer for others, I will update the README with a warning, stating that
pull_request_targetcan be used to steal secrets and will point users to autofix.ci.I have plans to publish a repository with example workflows in the coming months. The
pull_request_target-example will also have a big warning pointing out the security issues.Thanks @vincerubinetti for this detailed feedback with logs and workflows! Verifying and testing if and how this action still works with PRs is still on my todo list. Other projects nudged it down. Will try to take a closer look this weekend.
These logs help a lot!
Thanks for sharing this! Sounds lovely that it now seems to be possible to use this in PRs made by forks. Will do some verification and testing in my own repos and update the README.