Open PR Against Forks about create-pull-request

[peter-evans]

Yes, exactly. There are currently restrictions on events triggered by a pull request being opened from a fork. In fact, the restrictions are on any events triggered by a forked repository.

Restrictions on forked repositories

My understanding of the restrictions so far:

• Events from forks cannot access secrets, except for for the default GITHUB_TOKEN.

  With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

  ref: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets#using-encrypted-secrets-in-a-workflow

• The GITHUB_TOKEN has read-only access when an event is triggered by a forked repository.
  ref: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token#permissions-for-the-github_token

There are a couple of posts on the community forums about this issue and with confirmation from GitHub staff that they are trying to implement a security model that would allow it.
https://github.community/t5/GitHub-Actions/Can-t-push-to-forked-repository-on-the-original-repository-s/m-p/35916/highlight/true#M2372
https://github.community/t5/GitHub-Actions/Github-Workflow-not-running-from-pull-request-from-forked/m-p/37990/highlight/true#M3180

What that means for create-pull-request action

Currently, if the event was triggered by a forked repository, it cannot commit changes because the GITHUB_TOKEN is read-only. I've not even tried to implement it, so it actually fails before then when it tries to checkout the head branch.

On the todo list:

• (done) Add better handling to catch this case and present an understandable message
• (done) Consider if the action should exit silently in this particular case
• Write something in the README as a general explanation of what to expect when using the action with pull request events
• Add the ability to open a PR against a fork in future if it becomes possible. (Although I'm not sure if this is a use case anyone would want)

I think the use cases for using create-pull-request action during an on: pull_request event are slim anyway. What happens during those events is this:

1. The actions/checkout action by default checks out a merge commit between the head branch and the base.
2. create-pull-request action can't do anything with that merge commit, so it scraps it and checks out the head branch instead. (This is where it fails currently if the PR was raised from a fork)
3. If changes that were made on top of the merge commit before the action ran create a diff, the changes are committed to a new branch and a pull request raised with the base being the head branch of the original pull request. i.e. new-branch --> head_branch. Then the idea is that you would merge that new pull request into the first one before merging that.

The above all works fine for pull requests raised within a repository (non-fork PRs), but I think there are very few real use cases where you would want to do that kind of workflow.

The only other workflow I've seen work with on: pull_request and create-pull-request action is where the event is just being used to trigger the workflow for a completely different base. It doesn't make a lot of sense to do this because it's not really testing anything in the pull request, but it works. The following workflow is an example. It fixes the base to master by making sure it's checked out by actions/checkout before the changes are made, and then setting base: master on create-pull-request action.

on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
        with:
          ref: master
      - run: <something that creates a diff>
      - name: Create Pull Request
        uses: peter-evans/[email protected]
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          branch-suffix: none
          base: master

If in doubt I would advise just removing the pull_request event from a workflow that uses create-pull-request action.

[peter-evans]

I released a new version of the action today that gracefully handles pull request events triggered by forks. The action will report success but issue a warning that it couldn't handle the event.

[peter-evans]

Hrmm so if I change the trigger to an issue comment for “chatops” will it change the scope of permissions?

I'm currently investigating the same idea as a workaround for some operations. I've not got a complete solution that I'm satisfied with yet, but what I have discovered is that the GITHUB_TOKEN can be used to commit in issue_comment events even when triggered by a user that doesn't have write access to the repository. I think the reason this is possible is because issue_comment events can only execute code that has been committed by users with write access to the repository. That differs from pull_request because users without write access could potentially inject code via the PR to be executed by the workflow.

So yes, I'm fairly sure the scope of permissions for issue_comment events will allow "chatops" without restrictions.

[peter-evans]

Yes, very soon I'm going to publish a ChatOps solution I've been working on.

[osterman]

Thanks @peter-evans ! Your GitHub action is a “master class” in learning actions. That truly is a shame that we can’t use this action (or basically any action) on forks. As 99% of our projects are open source I am really struggling to accomplish many of the things I want to do. Hrmm so if I change the trigger to an issue comment for “chatops” will it change the scope of permissions?

[osterman]

@peter-evans any conclusions? =)

[peter-evans]

I've released an action called slash-command-dispatch that facilitates "ChatOps" with GitHub Actions.

There is a demo here that shows how this solution can be used to run workflows against pull requests.

[peter-evans]

I've released v2, a major version update. As part of this release I've summarised the main gist of my explanation of this issue in a new document here.

There are no changes to the approach. My recommendation is to use slash-command-dispatch to perform operations on pull requests.

Closing this issue for now.