Make PR to a different repo

[rabernat]

Thanks a lot for sharing this action!

I am trying to use it in a workflow to make a PR to a different repo. Specifically, I am trying to set up a workflow to make a PR to update a submodule in a different repo whenever the submodule target repo is changed.

The repo where the action is running is pangeo-gallery/example-gallery (the target of the submodule), while the repo where the submodule lives is pangeo-gallery/pangeo-gallery

I am getting this error:

warning: no common commits
From https://github.com/pangeo-gallery/example-gallery
 * [new branch]      binderbot-built -> binderbot-built
 * [new branch]      github-actions  -> github-actions
 + 84b9a01...bfc1e8d master          -> master  (forced update)
 * [new branch]      binderbot-built -> origin/binderbot-built
 * [new branch]      github-actions  -> origin/github-actions
 + 84b9a01...bfc1e8d master          -> origin/master  (forced update)
hub pull-request   -b master   -h binderbot-update   --no-edit   -m "Update pangeo-gallery/example-gallery submodule" -m ":crown: *An automated PR*"   || true
Error creating pull request: Unprocessable Entity (HTTP 422)
Invalid value for "head"

It looks like the action is trying to make the PR from pangeo-gallery/example-gallery, rather than pangeo-gallery/pangeo-gallery. I would like it to come from pangeo-gallery/pangeo-gallery, which I have already checked out earlier in my workflow.

Is this possible?

My workflow is here: https://github.com/pangeo-gallery/example-gallery/blob/master/.github/workflows/pangeo-gallery.yaml

You can see the log here: https://github.com/pangeo-gallery/example-gallery/runs/515467109?check_suite_focus=true#step:6:11

[wei]

You can try to manually set $GITHUB_REPOSITORY environment variable as this is what our action uses. If GitHub doesn't allow it you can create a PR to add it as an input.

[rabernat]

Thanks for the quick response.

You can try to manually set $GITHUB_REPOSITORY environment variable

This is explicitly forbidden. None of the environment variables prefixed by GITHUB_ can be changes. So I'll investigate a bit further and consider making a PR.

[wei]

Yep, that's what I figured, we'll need a new input pr_repository or something similar.

[sparksp]

I too would like to be able to create a pull request against another repo. My story:

I have a package repo that keeps the generated docs in source control. When someone makes a PR the job:

1. Checks out the code
2. Builds the docs
3. Creates a new branch
4. Commits any changes to new branch
5. If anything was committed, creates a new PR against this PR

This works great if the PR comes from the same repo, but otherwise the repo doesn't have the source branch to open the PR against. So I need to be able to PR against the originating fork - ideally without me having to figure out what that fork is.

[wei]

@sparksp Once pr_repository PR is in, you can write a small script to figure out the origin repo and provide it in a variable

[sparksp]

Thanks for responding! I actually found that I won't be able to do what I wanted because PR's raised by a fork get a read-only GitHub token so they can't make any changes at all. I don't want to go down the route of using a personal access token for this. So instead I'm now only creating PRs from push events instead of pull_request events.

[montanaflynn]

We want to this functionality as well, the use case is when a node package gets a version update to make PRs to several other repositories updating the package.json dependency version.

[wei]

@montanaflynn Does Does #59 fit your needs? It adds support to specify repository to make PR. We need some help with testing on that PR in order to merge it~

[montanaflynn]

I think it's a piece of what we're trying to achieve, first we need to checkout the repo, make a new branch, update the package.json, commit, push it, then make the PR. We are still in the idea phase but will reply back once we start implementing it. We have a node package that is used by several other repos and manually updating them is a pain.

[wei]

@montanaflynn A custom GitHub workflow is probably most suitable for your use-case. Feel free to contact me if you need any help~

[m4heshd]

@montanaflynn That's pretty much identical to what I'm currently doing. I'm using actions/checkout and doing the first part using git cli. For the PR, using this action with #69. I'm using this process in production without any hiccups.

[wei]

Resolved in #69.