Support using spr
from a fork
#110
Closed
+720
−57
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We make it possible for outside collaborators to use
spr
.The vast majority of the changes here are in adding some tests around
the changes in
src/config.rs
. Aside from that, this is amoderately-sized change "lines of code"-wise. The main thing here is
that we're taking in optional values for all of the upstream owner,
upstream repo, upstream remote, and upstream trunk. Even though they're
all optional, it's unclear what it would mean to only have one of the
four and use it. E.g. If we only have upstream owner, and we didn't
check the others existed, we might do something like push a branch to
origin and try to create a PR against an upstream that didn't exist.
Also, even though the origin and upstream trunks should likely be the
same, we still take it in just to be certain.
To make most things easier, the owner, repo, and trunk don't need to
quantify whether it's for origin or upstream outside of
Config
. Allthe external cases where those values are used, we want to use the
upstream if it exists and fallback to the origin otherwise. Internally,
we do make a distinction just because there are things we do
specifically on the origin no matter what.
There are two things we seem to have to make an active decision on: the
git remote name, and the pull request head.
For the remote name, it seems we always want to push to origin. And, it
seems like we always want to use upstream for landing/updating if it
exists and fallback to origin otherwise.
For the pull request head, it seems we need to construct some special
syntax if there's an upstream repo. It needs to mention the origin repo,
so it ends up looking like
<origin>:<branch>
instead of just<branch>
.All of these changes together mean that we should be able to use
spr
from a fork. Importantly, it means that
spr
should now be able to beused by outside collaborators to contribute to
spr
itself. The onlypart that's maybe a bit unclear is whether the stacked workflow will
actually work.
The API documentation seems to mention that the
base
parameter has toexist in the current repository:
https://docs.github.com/en/rest/pulls/pulls#create-a-pull-request--parameters.
Given the way stacking works with
spr
, it's unclear whether this willwork or not. We're optimistically assuming it will work. But we might
have to make some changes after the fact to support this flow.
Finally, we update the documentation to mention that there's a way to
use
spr
from a fork and mention the configuration values in theconfiguration reference documentation.
Test Plan:
There's two ways to view this change as working: recognize that I'm
making this change from a fork, and the fact that I can submit it is the
proof that it's working; or follow these steps yourself:
https://github.com/joneshf/spr-issue-80 if you need a repo.
docs/user/fork.md
file.
docs/user/simple.md
to make a simplechange and submit it to the upstream repo.