Allow to specify target repository

[rabernat]

This is my attempt to fix #18. My goal is to be able to make a PR to a different repo than $GITHUB_REPOSITORY, the repo running the action. I realized this is a bit more complicated, because we can't assume that the branches are both on the same repo. Furthermore, we can't assume the source branch even exists I think we need to:

• fork the base repo
• push the local changes to the fork
• issue the PR from the fork to the base

I can't figure out how to do the last two.

I realize this may add significant complexity that you don't want. But I thought I would share what I have so far.

[wei]

Thanks for the PR and the detailed analysis. Maybe we don't need to worry about forks? Users can checkout different repos using actions@checkout and this action can act on whatever repo that is checked out. Just need to make sure the token is the Personal access token for hub to have write access to create the PR. What do you think?

[rabernat]

Just need to make sure the token is the Personal access token for hub to have write access to create the PR. What do you think?

The scenario I'm thinking of is when the workflow does NOT have push credentials to upstream repo. If I want to make a PR to a repo that I don't have write access to, I first need to fork it, and then push a branch to that fork. Then I can create a PR.

[wei]

Workflow imo is something you want to keep rerunning. One-off tasks like creating the fork can be delegated to one-time manual creation or to a different action / script. Pushing changes can also be delegated to another action. This leaves pull-request action with the sole responsibility of PR creation. What do you think?

[weiji14]

Workflow imo is something you want to keep rerunning. One-off tasks like creating the fork can be delegated to one-time manual creation or to a different action / script. Pushing changes can also be delegated to another action. This leaves pull-request action with the sole responsibility of PR creation. What do you think?

Hi @wei (I'm Wei too!) and @rabernat (small world 😆). I'm quite interested in this too for conda-forge/gmt-feedstock#100, specifically the Pull Request creation from a fork (that's already created) to an upstream repository. Assuming that a fork is already present, does that mean this PR would work, or is there something else that is missing/more work to do?

[wei]

@weiji14 Hi Wei!!! I tried it with hub commandline but it doesn't seem to work with forks so closing this PR for now.

After cli/cli#1478 is fixed, you could do something like this:

    #TODO actions/checkout the branch in fork
    - name: Create PR
      env:
        GITHUB_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
        DESTINATION_BRANCH: <PARENT_REPO>:master
      run: |
        gh pr create --title "Title" --body "Body" --repo <PARENT_REPO>

[wei]

@weiji14 Updated the snippet above, you can run gh pr create --title "Title" --body "Body" --repo <PARENT_REPO>.

[weiji14]

Excellent, thanks for the quick follow up! I see too that there are more configuration options documented at https://cli.github.com/manual/gh_pr_create.

Quick question: Is the secrets.PERSONAL_ACCESS_TOKEN token necessary, or are we able to use secrets.GITHUB_TOKEN?

[wei]

@weiji14 I haven't tried GITHUB_TOKEN but I doubt it will work. Feel free to try it and let us know. 😃😃😃

[weiji14]

Yep, secrets.GITHUB_TOKEN doesn't work, it fails with the following message:

failed to create pull request: GraphQL error: Resource not accessible by integration

A quick search turns up actions/first-interaction#10, actions/labeler#50 and https://github.community/t/github-actions-are-severely-limited-on-prs/18179/2. According to https://docs.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token#permissions-for-the-github_token, the secrets.GITHUB_TOKEN only provides 'read' access to forked repos (instead of 'read/write'), and that:

"If you need a token that requires permissions that aren't available in the GITHUB_TOKEN, you can create a personal access token and set it as a secret in your repository:"

So secrets.PERSONAL_ACCESS_TOKEN it is then!