stefanzweifel / git-auto-commit-action

Automatically commit and push changed files back to GitHub with this GitHub Action for the 80% use case.
MIT License
1.98k stars 227 forks source link

Permission denied on PR from a fork #114

Closed VaibhavSaini19 closed 3 years ago

VaibhavSaini19 commented 3 years ago

Version of the Action v4.1.2

Describe the bug I have a workflow that uses this action to auto-commit the changes after pretty-formatting the desired files. It works fine when a PR is created by me. But when someone forks the repo, and creates a PR from there, the action fails, with the error: remote: Permission to VaibhavSaini19/BootBlox.git denied to github-actions[bot]. fatal: unable to access 'https://github.com/VaibhavSaini19/BootBlox/': The requested URL returned error: 403 I came to know about the recent changes using actions in forks from public repositories by GitHub, thorugh this, this, this and this. So I added the pull_request_target event as well, and asked the person who forked it to enable actions. Now, the action works successfully on the pull_request_target event, but still gives the permission denied error on pull_request event.

To Reproduce I am a little new to actions, so don't know if it is necessary to follow the below steps, or if a workflow can be directly accessed: Fork the repo, make some changes, create a PR

[Failed action]https://github.com/VaibhavSaini19/BootBlox/runs/1257606401?check_suite_focus=true

Expected behavior Changes to be committed automatically, like this

Screenshots Failed action

Screenshot (162)

Used Workflow

name: Format
on:
    pull_request:
        branches: [master]
    pull_request_target:
        branches: [master]
jobs:
    format:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v2
              with:
                  ref: ${{ github.head_ref }}
            - uses: actions/setup-node@v1
              with:
                  node-version: "12.x"
            - name: Format
              run: |
                  yarn install --frozen-lockfile
                  yarn run format
            - name: Commit changes
              uses: stefanzweifel/git-auto-commit-action@v4.1.2
              with:
                  commit_message: Apply formatting changes
                  branch: ${{ github.head_ref }}
stefanzweifel commented 3 years ago

I think the problem here is, the workflow is listening to bothpull_request and pull_request_target events. That's probably a bad wording on my part, as the README states.

In addition to listening to the pull_request event in your Workflow triggers, you have to add an additional event: pull_request_target

Reading the docs about pull_request_target-again I think pull_request can safely be removed from the workflow.

If you, as the repo owner, open a pull request, the workflow should also be triggered through the pull_request_target-event.

However, this PR in your repo shows that the pull_request_target run for "Format" was successful, but the commit is no where to be found 🤔

Could you give it a try without pull_request? And maybe with an update from v4.1.2 to just v4 (is always the latest version).


I also thought it could be related to the older version you're using, but the compare view doesn't show any changes related to pushing. Compare view

VaibhavSaini19 commented 3 years ago

Could you give it a try without pull_request? And maybe with an update from v4.1.2 to just v4 (is always the latest version).

Okay, I'll switch to v4, remove the pull_request trigger and let you know the results.

However, this PR in your repo shows that the pull_request_target run for "Format" was successful, but the commit is no where to be found 🤔

I was wondering about the same, then I realized that a commit has been made to the master branch around same time, by the person who made the PR and action-users, check this I'm sure I haven't approved the PR or merged anything. Then how was this commit made to the master?

Does listening to pull_request_trigger allow actions on forks to directly commit to the original repo?

stefanzweifel commented 3 years ago

I was wondering about the same, then I realized that a commit has been made to the master branch around same time, by the person who made the PR and action-users, check this I'm sure I haven't approved the PR or merged anything. Then how was this commit made to the master?

Oh no. That probably shouldn't happen. Maybe this was possible, because the PR branch name was also master? Maybe it's related to branches-setting for pull_request_target?

     pull_request_target:
-         branches: [master]

I would have to make some investigations. Maybe this should even be reported to GitHub itself 🤔

VaibhavSaini19 commented 3 years ago

Maybe this was possible, because the PR branch name was also master?

I specifically asked that person to first merge the changes from his branch to the master branch of the fork, because if a PR was being created from a branch of fork to the master of original repo, the checkout action was failing while fetching the repo (like this). I know this isn't the right place to ask about this issue, but do you have any idea as to why that might be happening (Again, when I create a branch and open a PR, the action works fine)

stefanzweifel commented 3 years ago

[…] but do you have any idea as to why that might be happening […]

Not really :/

Maybe it's all related to which triggers are used in the workflow? In most of my repos, I use a combination of push and pull_request (see below).

I could even remove the github.head_ref part from theactions/checkout`-step and it still works.

on:
  push:
    branches:
      - master
  pull_request:

jobs:
  php-cs-fixer:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2

    - name: Run php-cs-fixer
      uses: docker://oskarstark/php-cs-fixer-ga

    - uses: stefanzweifel/git-auto-commit-action@v4

I'm literally confused myself how this even works and why we have a passage to require github.head_ref in the README. (But that's another story)

VaibhavSaini19 commented 3 years ago

Removed the github.head_ref part. So now, a PR from a branch of a fork towards the master of original repo successfully passes the checks (given the fork has actions enabled)

I guess we can close this issue for now, and you can probably update the readme file.

Thank you for your help 😄