Limitations on PRs from forks no longer apply
ConorMacBride opened this issue · 19 comments
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! 🎉
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.
Just did a quick test in a playground repository, where the commits were made by a user that is not a contributor to the repository: stefanzweifel/git-auto-commit-action-demo-app#33
- The workflow file has been updated to use
repository: ${{ github.event.pull_request.head.repo.full_name }}and listen to thepull_request_targetevent. - GitHub Actions is disabled in the forked repository
The run fails due to a permission error:
remote: Permission to wnxtrash/git-auto-commit-action-demo-app.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/wnxtrash/git-auto-commit-action-demo-app/': The requested URL returned error: 403
… which is honestly something I expected. GitHub introduced these contraints as a security measure against bad actors. I would have been surprised if they removed them. There was also no announcement from GitHub about such a change on their official channels (blog, Twitter).
I assume your workflow run was successful, as you're a member of the sunpy Github organization? In my example the wnxtrash User has no affiliation with the test repo. And therefore doesn't have push rights.
I'm closing this issue for now.
The pull_request_target trigger 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 from stefanzweifel/git-auto-commit-action-demo-app (main) and not wnxtrash/git-auto-commit-action-demo-app (main). So you have full control of the actions that are run and it is therefore trusted with a GITHUB_TOKEN with write permissions.
Here's an example of a workflow running with write permission 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
The security measure is that GitHub Actions runs the version of the workflow from stefanzweifel/git-auto-commit-action-demo-app (main) and not wnxtrash/git-auto-commit-action-demo-app (main). So you have full control of the actions that are run and it is therefore trusted with a GITHUB_TOKEN with write permissions.
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. stefanzweifel/git-auto-commit-action-demo-app#34
Will update the README shortly with an example using repository: ${{ github.event.pull_request.head.repo.full_name }}.
@stefanzweifel @ConorMacBride Although this is incredibly useful, doing this would introduce security vulnerabilities. Quoting from the link:
TL;DR: Combining
pull_request_targetworkflow trigger with an explicit checkout of an untrusted PR is a dangerous practice that may lead to repository compromise.
I think it is important to point it out in the README.md section for all the users of this action.
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:test into vincerubinetti/lab-website-template:main (I also tried main into main). I'm still getting the error:
remote: Permission to greenelab/lwt-test.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/greenelab/lwt-test/': The requested URL returned error: 403
Error: Invalid status code: 128
Both repos also have Actions enabled, and the most permissive settings:
- Allow all actions and reusable workflows
- Fork pull request workflows from outside collaborators: Require approval for first-time contributors who are new to GitHub
- Workflow permissions: read and write permissions
I happen to be an admin under both organizations, vincerubinetti and greenelab.
triggering workflow
name: on-pull-request
run-name: on pull request activity
on:
pull_request_target:
types:
- opened
- reopened
- synchronize
- closed
jobs:
update-citations:
uses: ./.github/workflows/update-citations.yaml
build-preview:
needs: update-citations
uses: ./.github/workflows/build-preview.yamlcalled workflow
name: update-citations
run-name: update citations
on:
# run when called from another workflow
workflow_call:
outputs:
changed:
value: ${{ jobs.update-citations.outputs.changed }}
# run if user manually requests it
workflow_dispatch:
env:
FORCE_COLOR: true
GOOGLE_SCHOLAR_API_KEY: ${{ secrets.GOOGLE_SCHOLAR_API_KEY }}
jobs:
update-citations:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- name: Checkout branch contents
uses: actions/checkout@v3
with:
repository: ${{ github.event.pull_request.head.repo.full_name }}
ref: ${{ github.head_ref }}
- name: Setup Python
uses: actions/setup-python@v4
with:
python-version: "3.11"
cache: "pip"
cache-dependency-path: "**/requirements.txt"
- name: Install Python packages
run: |
python -m pip install --upgrade --requirement ./_cite/requirements.txt
- name: Build updated citations
run: python _cite/cite.py
timeout-minutes: 15
- name: Check if citations changed
uses: tj-actions/verify-changed-files@v13
id: changed
with:
files: |
_data/citations.yaml
- name: Commit updated citations
if: steps.changed.outputs.files_changed == 'true'
uses: stefanzweifel/git-auto-commit-action@v4
with:
commit_message: "Update citations"
outputs:
changed: ${{ steps.changed.outputs.files_changed }}logs
Setup Job
Operating System
Runner Image
Runner Image Provisioner
2.0.108.1
GITHUB_TOKEN Permissions
Actions: write
Checks: write
Contents: write
Deployments: write
Discussions: write
Issues: write
Metadata: read
Packages: write
Pages: write
PullRequests: write
RepositoryProjects: write
SecurityEvents: write
Statuses: write
Secret source: Actions
Prepare workflow directory
Prepare all required actions
Getting action download info
Download action repository 'actions/checkout@v3' (SHA:ac593985[6](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:1:7)15ec2ede58e132d2e21d2b1cbd6127c)
Download action repository 'actions/setup-python@v4' (SHA:d27e3f3d7c64b4bbf8e4abfb9b63b83e846e0435)
Download action repository 'tj-actions/verify-changed-files@v13' (SHA:9ed3155b72ba709881c967f756[11](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:1:13)fc5852f773b9)
Download action repository 'stefanzweifel/git-auto-commit-action@v4' (SHA:3ea6ae190baf489ba007f7c92608f33ce20ef04a)
Getting action download info
Download action repository 'tj-actions/glob@v16' (SHA:9923edc8efb605c[13](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:1:16)1fb09a79699a819cde2cfe4)
Uses: vincerubinetti/lab-website-template/.github/workflows/update-citations.yaml@refs/heads/main (aaa73ec57a96be57e8098b75ac02e0[16](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:1:19)4e[35](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:1:39)bf9a)
Complete job name: update-citations / update-citations
Checkout branch contents
Run actions/checkout@v3
with:
repository: greenelab/lwt-test
ref: test
token: ***
ssh-strict: true
persist-credentials: true
clean: true
fetch-depth: 1
lfs: false
submodules: false
set-safe-directory: true
env:
FORCE_COLOR: true
GOOGLE_SCHOLAR_API_KEY:
Syncing repository: greenelab/lwt-test
Getting Git version info
Working directory is '/home/runner/work/lab-website-template/lab-website-template'
/usr/bin/git version
git version 2.[3](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:3)9.1
Temporarily overriding HOME='/home/runner/work/_temp/1b0c68[4](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:4)e-682a-4fd7-88[5](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:5)a-14[6](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:6)24c45f58[7](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:7)' before making global git config changes
Adding repository directory to the temporary git global config as a safe directory
/usr/bin/git config --global --add safe.directory /home/runner/work/lab-website-template/lab-website-template
Deleting the contents of '/home/runner/work/lab-website-template/lab-website-template'
Initializing the repository
/usr/bin/git init /home/runner/work/lab-website-template/lab-website-template
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /home/runner/work/lab-website-template/lab-website-template/.git/
/usr/bin/git remote add origin https://github.com/greenelab/lwt-test
Disabling automatic garbage collection
/usr/bin/git config --local gc.auto 0
Setting up auth
/usr/bin/git config --local --name-only --get-regexp core\.sshCommand
/usr/bin/git submodule foreach --recursive sh -c "git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :"
/usr/bin/git config --local --name-only --get-regexp http\.https\:\/\/github\.com\/\.extraheader
/usr/bin/git submodule foreach --recursive sh -c "git config --local --name-only --get-regexp 'http\.https\:\/\/github\.com\/\.extraheader' && git config --local --unset-all 'http.https://github.com/.extraheader' || :"
/usr/bin/git config --local http.https://github.com/.extraheader AUTHORIZATION: basic ***
Fetching the repository
/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/heads/test*:refs/remotes/origin/test* +refs/tags/test*:refs/tags/test*
remote: Enumerating objects: 160, done.
remote: Counting objects: 0% (1/160)
Resolving deltas: 100% (5/5), done.
From https://github.com/greenelab/lwt-test
* [new branch] test -> origin/test
Determining the checkout info
/usr/bin/git branch --list --remote origin/test
origin/test
Checking out the ref
/usr/bin/git checkout --progress --force -B test refs/remotes/origin/test
Switched to a new branch 'test'
branch 'test' set up to track 'origin/test'.
/usr/bin/git log -1 --format='%H'
'11c318f717d81c5ec98c15049803de635270[39](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:42)6f'
Commit updated citations
Run stefanzweifel/git-auto-commit-action@v4
Started: bash /home/runner/work/_actions/stefanzweifel/git-auto-commit-action/v4/entrypoint.sh
INPUT_REPOSITORY value: .
INPUT_STATUS_OPTIONS:
INPUT_FILE_PATTERN: .
INPUT_BRANCH value: test
From https://github.com/greenelab/lwt-test
* [new branch] main -> origin/main
Already on 'test'
M _cite/.cache/cache.db
M _data/citations.yaml
Your branch is up to date with 'origin/test'.
INPUT_ADD_OPTIONS:
INPUT_FILE_PATTERN: .
INPUT_COMMIT_OPTIONS:
INPUT_COMMIT_USER_NAME: github-actions[bot]
INPUT_COMMIT_USER_EMAIL: 41898282+github-actions[bot]@users.noreply.github.com
INPUT_COMMIT_MESSAGE: Update citations
INPUT_COMMIT_AUTHOR: vincerubinetti <vincerubinetti@users.noreply.github.com>
[test 542c0d4] Update citations
Author: vincerubinetti <vincerubinetti@users.noreply.github.com>
2 files changed, 10 insertions(+)
INPUT_TAGGING_MESSAGE:
No tagging message supplied. No tag will be added.
INPUT_PUSH_OPTIONS:
remote: Permission to greenelab/lwt-test.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/greenelab/lwt-test/': The requested URL returned error: [40](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:43)3
Error: Invalid status code: 128
at ChildProcess.<anonymous> (/home/runner/work/_actions/stefanzweifel/git-auto-commit-action/v4/index.js:17:19)
at ChildProcess.emit (node:events:[52](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:57)7:28)
at maybeClose (node:internal/child_process:10[92](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:97):16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5) {
code: 128
}
Error: Invalid status code: 128
at ChildProcess.<anonymous> (/home/runner/work/_actions/stefanzweifel/git-auto-commit-action/v4/index.js:17:19)
at ChildProcess.emit (node:events:527:28)
at maybeClose (node:internal/child_process:[109](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:114)2:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:[302](https://github.com/vincerubinetti/lab-website-template/actions/runs/4117682412/jobs/7109283248#step:2:307):5)
Link to run (will dissappear in the future): https://github.com/vincerubinetti/lab-website-template/actions/runs/4118566556/jobs/7111241089
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.
Next time a user forks your project and enabled GitHub Actions and opened a Pull Request, the Workflow will run on the forked repository and will push commits to the same branch.
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:
No pull request events occur on the forked repository.
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.
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 looking into this. To be clear, I think it's pretty clearly a GitHub issue, not an issue with this action, but it helps to have someone more competent than myself helping. I'm not sure how @ConorMacBride and you were able to get this working in the middle of last year. Maybe something changed since then...
Fwiw, I've tried so many things. One thing I recently tried was using the checkout action to checkout the fork, do my modifications, copy the changed files to an upper folder, then do a normal checkout (with various permutations), then push with git-auto-commit. Nothing has worked.
If you're a git wizard (I'm definitely not), I might recommend trying to SSH into a running workflow using Tmate. Then you could poke around, switch branches/refs/etc, and see what GitHub allows you to push: - uses: mxschmitt/action-tmate@v3. Much more rapid and realtime. I tried to do this a bit, but I simply don't understand Git and GitHub well enough.
@vincerubinetti I also only know learned that GitHub updated the default permissions of the GITHUB_TOKEN last Tuesday to ready-only.
https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/
If you've tested this in a new repository, you might now need to set permissions for the token or change the settings in the repository. (They've introduced permissions in 2021: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/)
permissions:
contents: write
steps:
- uses: actions/checkout@v3
- # Change repo
- uses: stefanzweifel/git-auto-commit-action@v4Still need to test and document this.
Unfortunately I couldn't get it to work with that either (setting it in both the caller and called workflows in my case).
I think I had already noticed that the default for new repos started being the second option, where you only get read access for contents. But as I mentioned in a previous comment, I've been making sure to set it to the first option to give write access to all scopes. So I would think any setting of permissions in the workflow shouldn't be needed anyway?
Here's an article that might be useful:
https://joht.github.io/johtizen/build/2022/01/20/github-actions-push-into-repository.html
https://github.com/EndBug/add-and-commit#working-with-prs
Need to step away from the problem a bit because I'm going crazy, but tag me if you have new info/understanding/debugging tips/whatever.
I think I almost figured it out @vincerubinetti
As GitHub changed the default permissions of the GITHUB_TOKEN for new repositories, I've created a fresh new repository to test the action.
I've added the following workflow that listens to the push and pull_request_target triggers. It appends the current time to a markdown file.
name: Update File
on:
push:
branches:
- main
pull_request_target:
workflow_dispatch:
jobs:
update-file:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v3
with:
repository: ${{ github.event.pull_request.head.repo.full_name }}
ref: ${{ github.head_ref }}
- run: echo - $(date +%Y-%m-%d-%H-%M-%S) >> file-to-update.md
- uses: stefanzweifel/git-auto-commit-action@v4
with:
commit_message: Commit made through git-auto-commitThe settings in the repository have not been updated. By default the GITHUB_TOKEN has only read permissions; though I change that in the workflow by setting contents: write.
With another GitHub account I've created a fork of the repository. (I've enabled GitHub Actions in the fork, as they are disabled by default after forking)
On the fork, I made a simple change to a markdown file and opened a pull request on the original repository.
GitHub Actions then ran my workflow in the original repository only and successfully updated the markdown file and pushed it to the fork. (stefanzweifel/git-auto-commit-demo-app@0ac8ebe)
This is basically the same setup as you have @vincerubinetti. But you still ran into permission issues. :/
Two things came to mind that could block the write access:
- On https://github.com/vincerubinetti/lab-website-template/pull/13: Has the "Allow edits and access to secrets by maintainers" checkbox been checked?
- Highly unlikely: Are any branches in both repositories protected by branch rules?
I assume when the "Allow edits and access to secrets by maintainers"-checkbox is not checked, that the original repository doesn't have the permission to push something to the fork.
Protected branches can't be circumvented with a default GITHUB_TOKEN. A personal access token is always required.
https://github.com/stefanzweifel/git-auto-commit-action#push-to-protected-branches
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:
No pull request events occur on the forked repository.
This makes me think the "Workflow should run in forked repository" of your readme isn't right somehow...
I think I can confirm that.
I was only able to trigger a run in the fork when I accidentally opened a pull request in the same forked repository.
- https://github.com/wnxtrash/git-auto-commit-demo-app/actions/runs/4157820501
- wnxtrash/git-auto-commit-demo-app#1
Will update the docs about this soon.
@stefanzweifel Thank you for all of your hard work looking into this.
I did see your readme instructions about "Allow edits by maintainers", but while testing, I actually never saw that option appear in my GitHub UI! Now that I think about it more, I'm betting that this is the source of the issue.
Check out this issue:
https://github.com/orgs/community/discussions/5634
The way I was testing out my workflow was merging in a fork from greenelab into vincerubinetti. The latter is my personal account obviously. The former is an organization... one that I have the highest permissions in (owner).
Apparently, according to that issue, GitHub doesn't allow "edits by maintainers" from org forks!!! 🙃 I tried the same test the other way around (vincerubinetti into greenelab), I had the checkbox available, I left it checked, and lo-and-behold this action was able to commit with no problems!
It's not your responsibility to do so, but maybe next to your "Allow edits by maintainers" you could put a small warning about org forks and link to that discussion.
@vincerubinetti Didn't know about that limitation of org forks. Thanks for investigating.
It's not your responsibility to do so, but maybe next to your "Allow edits by maintainers" you could put a small warning about org forks and link to that discussion.
Will do!
@stefanzweifel @ConorMacBride Although this is incredibly useful, doing this would introduce security vulnerabilities. Quoting from the link:
TL;DR: Combining
pull_request_targetworkflow trigger with an explicit checkout of an untrusted PR is a dangerous practice that may lead to repository compromise.I think it is important to point it out in the
README.mdsection for all the users of this action.
Similarly I'm not sure if usage of pull_request_target is secure here.
Warning: For workflows that are triggered by the pull_request_target event, the GITHUB_TOKEN is granted read/write repository permission unless the permissions key is specified and the workflow can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch. To help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see "Keeping your GitHub Actions and workflows secure: Preventing pwn requests" on the GitHub Security Lab website.
Here an explicit permission is set, which seems fine? 🤔
If the workflow can access secrets then an attacker just has to update the CI commands in their PR to steal secrets?
If the workflow can access secrets then an attacker just has to update the CI commands in their PR to steal secrets?
In my test repository I added a secret and updated the workflow to echo out that workflow. GitHub is clever enough and will never actually display the secret value in the log files.
https://github.com/stefanzweifel/git-auto-commit-action-demo-app/actions/runs/7105521724/job/19342893706#step:6:28
But a bad-actor could theoretically update the workflow to consume the secret by using their own code and potentially steal the secret. So yeah, pull_request_target isn't 100% secure either.
More than happy to hear ideas for improvements for the docs in the README or even pull requests for that.
Thanks for the test.
If it's not logged in their UI, it doesn't mean that users can't steal the secret unfortunately, so I'm not sure it's super safe.
Honestly this pull_request_target is turning my brain upside down. It's hard to reason about and even be 100% sure its usage is safe. Last time I used it on Docusaurus after carefully reading the doc and trying to be secure, Meta security team audited it a few months later and found out it's possible to exploit it, and asked me to remove usage. contacted me a few months later explaining me it's possible.
Author of competing solution "autofix.ci" apparently says it's unsafe, and built a product around that limitation (https://twitter.com/maximilianhils/status/1723715268407427338)
If it's not logged in their UI, it doesn't mean that users can't steal the secret unfortunately, so I'm not sure it's super safe.
I agree. pull_request_target isn'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_target can 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
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
slorber/lint-autofix-ci-demo#1
I tried splitting the workflow 2 as suggested:
- "pull_request" (untrusted linting, generate git diff patch)
- "workflow_run" (trusted, apply patch and push)
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