Fix branch name #649
Merged
Fix branch name #649
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fthomas
reviewed
Jul 2, 2019
modules/core/src/main/scala/org/scalasteward/core/nurture/NurtureAlg.scala
Show resolved
Hide resolved
daddykotex
force-pushed
the
branch-name-gitlab
branch
from
a9d7477
to
5c257a5
Compare
Codecov Report
@@ Coverage Diff @@
## topic/gitlab #649 +/- ##
================================================
- Coverage 57.9% 57.44% -0.47%
================================================
Files 73 71 -2
Lines 974 954 -20
Branches 21 26 +5
================================================
- Hits 564 548 -16
+ Misses 410 406 -4
Continue to review full report at Codecov.
|
During merge/rebase, I may have accidentally changed the branch name used when creating the MR. On Gitlab, we need `update/dependency-1.2.0` where as on GitHub we need: `owner:update/dependency-1.2.0`.
daddykotex
force-pushed
the
branch-name-gitlab
branch
from
5c257a5
to
13b3ac9
Compare
|
Removed the whole |
fthomas
approved these changes
Jul 3, 2019
This was referenced Feb 28, 2024
rtyley
added a commit
to rtyley/scala-steward
that referenced
this pull request
Feb 29, 2024
… Pull Requests As described in scala-steward-org#3300, Scala Steward has been using a now-invalid form of `head` query parameter when querying for existing GitHub Pull Requests. This has meant that it's been trying to raise new pull requests when existing ones with the same branch name were already present, leading to exceptions from the GitHub API. The `head` parameter being used would look like: ``` [organization]/[repo]:[ref-name] ``` ...however the documentation for the `List pull requests` endpoint says it should be just: ``` [organization]:[ref-name] ``` (see https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#list-pull-requests) ...it actually _does_ make sense to _not_ have the repo name in there, as it _is_ redundant - the path in the REST API request already contains /repos/{owner}/{repo}/pulls, giving the original repo, and GitHub only allows one fork of a repo per organisation or user, so including the user or org in the prefix should be sufficient to uniquely identify a fork. Although the `[organization]/[repo]:[ref-name]` format must have worked in the past, it looks like GitHub must have made a change that means if you use it to search for PRs by branch name _now_, you'll get zero results - the PRs we're interested in won't come back. Consequently, this change updates Scala Steward to use the approved `head` parameter format, dropping the `/[repo]` part. The code in Scala Steward that constructed the parameter _was_ in the `forge.listingBranch()` method, but once it was fixed to remove `/[repo]`, it became identical to the `forge.createBranch()` method, and so it made sense to go from having 2 methods back to just 1 (there was originally just one `headFor` method back before PR scala-steward-org#649).
mzuehlke
pushed a commit
that referenced
this pull request
Feb 29, 2024
As described in #3300, Scala Steward has been using a now-invalid form of `head` query parameter when querying for existing GitHub Pull Requests. This has meant that it's been trying to raise new pull requests when existing ones with the same branch name were already present, leading to exceptions from the GitHub API. The `head` parameter being used would look like: ``` [organization]/[repo]:[ref-name] ``` ...however the documentation for the `List pull requests` endpoint says it should be just: ``` [organization]:[ref-name] ``` (see https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#list-pull-requests) ...it actually _does_ make sense to _not_ have the repo name in there, as it _is_ redundant - the path in the REST API request already contains /repos/{owner}/{repo}/pulls, giving the original repo, and GitHub only allows one fork of a repo per organisation or user, so including the user or org in the prefix should be sufficient to uniquely identify a fork. Although the `[organization]/[repo]:[ref-name]` format must have worked in the past, it looks like GitHub must have made a change that means if you use it to search for PRs by branch name _now_, you'll get zero results - the PRs we're interested in won't come back. Consequently, this change updates Scala Steward to use the approved `head` parameter format, dropping the `/[repo]` part. The code in Scala Steward that constructed the parameter _was_ in the `forge.listingBranch()` method, but once it was fixed to remove `/[repo]`, it became identical to the `forge.createBranch()` method, and so it made sense to go from having 2 methods back to just 1 (there was originally just one `headFor` method back before PR #649).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
During merge/rebase, I may have accidentally changed the
branch name used when creating the MR. On Gitlab, we need
update/dependency-1.2.0where as on GitHub we need:owner:update/dependency-1.2.0.