-
Notifications
You must be signed in to change notification settings - Fork 496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Improve branch selection #2281
Proposal: Improve branch selection #2281
Conversation
Signed-off-by: Alejandro Hernández <[email protected]>
Signed-off-by: Alejandro Hernández <[email protected]>
Signed-off-by: Alejandro Hernández <[email protected]>
Signed-off-by: Alejandro Hernández <[email protected]>
Signed-off-by: Alejandro Hernández <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #2281 +/- ##
==========================================
- Coverage 77.83% 77.82% -0.01%
==========================================
Files 135 135
Lines 2287 2291 +4
Branches 51 50 -1
==========================================
+ Hits 1780 1783 +3
- Misses 507 508 +1
Continue to review full report at Codecov.
|
Signed-off-by: Alejandro Hernández <[email protected]>
…lt one Signed-off-by: Alejandro Hernández <[email protected]>
I really would like to have this feature in Scala Steward but more changes are needed to properly support multiple branches. (Some of them were in #1469.) For example, for each branch we need to have different |
I can try to include the changes in the linked PR |
Signed-off-by: Alejandro Hernández <[email protected]>
Hey @fthomas I've already included all the missing changes in #1469. I believe the cache issue is resolved, given that the cache is created using the The only missing thing would be to try this using fork (I've already tried it using the Once we are happy with the solution, I can update README and documentation, and create a PR for the GitHub Action. |
Signed-off-by: Alejandro Hernández <[email protected]>
Signed-off-by: Alejandro Hernández <[email protected]>
I've checked with this test repo (using
|
Also, it seems the |
It was added in this ancient commit and was required for the |
I could run it locally on https://github.com/scala-steward-org/test-repo-2 if you like. I created a new |
I just tried it locally:
|
This is unused since #1220. See #2281 (comment).
This adds `Repo.toPath` which has currently the same implementation as `Repo.show`. `show` is used as representation in log messages while `toPath` is used as path components. This allows us in #2281 to use `owner/repo:branch` for `show` and `owner/repo/branch` for `toPath`.
modules/core/src/main/scala/org/scalasteward/core/vcs/package.scala
Outdated
Show resolved
Hide resolved
…ch-selection-to-repos-file Signed-off-by: Alejandro Hernández <[email protected]> # Conflicts: # modules/core/src/main/scala/org/scalasteward/core/vcs/data/Repo.scala # modules/core/src/main/scala/org/scalasteward/core/vcs/package.scala # modules/core/src/test/scala/org/scalasteward/core/vcs/data/RepoTest.scala
modules/core/src/main/scala/org/scalasteward/core/vcs/data/Repo.scala
Outdated
Show resolved
Hide resolved
I'll revert this since |
Signed-off-by: Alejandro Hernández <[email protected]>
Signed-off-by: Alejandro Hernández <[email protected]>
I've added this PR in the |
I noticed this feature didn't take into account users running Scala Steward for a GitHub App. For those users the only option would be to have something in the repo (some kind of file) that lists the branches to update and request that file via API. The only problem is that the REST API has a rate-limit of 5000 calls per-hour, so I investigated it using the GraphQL API (that allows to query several repos at once) and this is the output: So to sum up, we could change the way the branch is added, so it is added to the What do you think @fthomas? |
For example this is the output for the first 100 repositories listed in the GitHub {
"data": {
"r1": {
"object": null
},
"r2": {
"object": null
},
"r3": {
"object": null
},
"r4": {
"object": null
},
"r5": {
"object": null
},
"r6": {
"object": null
},
"r7": {
"object": {
"text": "updates.includeScala = true\n"
}
},
"r8": {
"object": null
},
"r9": {
"object": null
},
"r10": {
"object": {
"text": "updates.ignore = [\n { groupId = \"com.typesafe\", artifactId = \"ssl-config-core\" },\n\n { groupId = \"com.typesafe.akka\", artifactId = \"akka-actor\" },\n { groupId = \"com.typesafe.akka\", artifactId = \"akka-actor-typed\" },\n { groupId = \"com.typesafe.akka\", artifactId = \"akka-discovery\" },\n { groupId = \"com.typesafe.akka\", artifactId = \"akka-slf4j\" },\n { groupId = \"com.typesafe.akka\", artifactId = \"akka-stream\" },\n { groupId = \"com.typesafe.akka\", artifactId = \"akka-stream-testkit\" },\n { groupId = \"com.typesafe.akka\", artifactId = \"akka-testkit\" },\n { groupId = \"com.typesafe.akka\", artifactId = \"akka-multi-node-testkit\" },\n\n { groupId = \"com.typesafe.akka\", artifactId = \"akka-http\" },\n { groupId = \"com.typesafe.akka\", artifactId = \"akka-http-core\" },\n\n { groupId = \"org.scalatest\", artifactId = \"scalatest\" },\n]\n\nupdates.pin = [\n { groupId = \"org.scalatest\", artifactId = \"scalatest\", version = \"3.1.\" },\n]\n"
}
},
"r11": {
"object": null
},
"r12": {
"object": null
},
"r13": {
"object": null
},
"r14": {
"object": null
},
"r15": {
"object": null
},
"r16": {
"object": null
},
"r17": {
"object": null
},
"r18": {
"object": {
"text": "updates.ignore = [ { groupId = \"org.apache.spark\", artifactId = \"spark-sql\" } ]\n"
}
},
"r19": {
"object": null
},
"r20": {
"object": null
},
"r21": {
"object": null
},
"r22": {
"object": null
},
"r23": {
"object": {
"text": "updates.ignore = [ { groupId = \"org.apache.spark\", artifactId = \"spark-sql\" } ]\n"
}
},
"r24": {
"object": null
},
"r25": {
"object": null
},
"r26": {
"object": null
},
"r27": {
"object": null
},
"r28": {
"object": null
},
"r29": {
"object": null
},
"r30": {
"object": null
},
"r31": {
"object": null
},
"r32": {
"object": null
},
"r33": {
"object": null
},
"r34": {
"object": null
},
"r35": {
"object": null
},
"r36": {
"object": null
},
"r37": {
"object": null
},
"r38": {
"object": null
},
"r39": {
"object": null
},
"r40": {
"object": null
},
"r41": {
"object": null
},
"r42": {
"object": null
},
"r43": {
"object": null
},
"r44": {
"object": {
"text": "updatePullRequests = \"always\"\ncommits.message = \":arrow_up: update ${artifactName} from ${currentVersion} to ${nextVersion}\"\n"
}
},
"r45": {
"object": null
},
"r46": {
"object": null
},
"r47": {
"object": null
},
"r48": {
"object": null
},
"r49": {
"object": null
},
"r50": {
"object": null
},
"r51": {
"object": null
},
"r52": {
"object": null
},
"r53": {
"object": null
},
"r54": {
"object": null
},
"r55": {
"object": null
},
"r56": {
"object": null
},
"r57": {
"object": null
},
"r58": {
"object": null
},
"r59": {
"object": null
},
"r60": {
"object": null
},
"r61": {
"object": null
},
"r62": {
"object": null
},
"r63": {
"object": null
},
"r64": {
"object": null
},
"r65": {
"object": null
},
"r66": {
"object": null
},
"r67": {
"object": null
},
"r68": {
"object": null
},
"r69": {
"object": null
},
"r70": {
"object": null
},
"r71": {
"object": null
},
"r72": {
"object": null
},
"r73": {
"object": null
},
"r74": {
"object": null
},
"r75": {
"object": null
},
"r76": {
"object": null
},
"r77": {
"object": null
},
"r78": {
"object": null
},
"r79": {
"object": null
},
"r80": {
"object": null
},
"r81": {
"object": null
},
"r82": {
"object": null
},
"r83": {
"object": null
},
"r84": {
"object": null
},
"r85": {
"object": null
},
"r86": {
"object": null
},
"r87": {
"object": null
},
"r88": {
"object": null
},
"r89": {
"object": null
},
"r90": {
"object": null
},
"r91": {
"object": null
},
"r92": {
"object": {
"text": "updates.pin = [ { groupId = \"org.typelevel\", artifactId=\"cats-effect\", version = \"2.\" } ]\n"
}
},
"r93": {
"object": null
},
"r94": {
"object": null
},
"r95": {
"object": null
},
"r96": {
"object": null
},
"r97": {
"object": null
},
"r98": {
"object": null
},
"r99": {
"object": null
},
"r100": {
"object": null
}
}
} We would just need to find something similar for GitLab/BitBucket users. Although given the amount of usage those have for the public Scala Steward, we could just go with doing one call per repository to retrieve the file. |
Oh nooo. 😱 That's the curse of having so many features. Can't we just not support branch selection if it used as GitHub App? |
I suppose. Whatever you prefer, I don't mind trying to implement it. The possible benefit if we can make this work would be that nobody would need to send a PR for updating the But if you are happy with not supporting multi-branch for GitHub Apps and continue with the current implementation it's fine by me 😸 |
What I like about the current approach is that no branch is really special. It is possible to get updates for a branch that is not the default branch without configuring anything in the default branch. If branches are configured via
Great, then let's continue with the current implementation! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Outstanding work @alejandrohdezma!
I'd be happy to merge this PR now. @alejandrohdezma is there anything left you want to do before I hit the merge button? |
Nothing that I can think of :) |
This feature works great! Here are two random PRs in the same repo targeting different branches: |
How is the feature working, since a new version hasn't been published yet? |
My public instance tracks Should we publish a new version for the GH Action soon? |
Oh, that's nice. Yeah, that would be super :) I'm adding a PR for supporting the new |
0.12.0 is now available. |
What has been done in this PR?
This PR improves the branch selection feature added in #2183 by allowing to be used not only for users of the
scala-steward-action
or users that run their own instance of Steward, but to anyone using therepos.md
feature.How?
Instead of receiving the default branch to use from the CLI, I've updated the
repos.md
parser to also allow the following syntax:The
Repo
class has been updated with a new fieldbranch: Option[Branch]
. If that field is present, that branch will be used as the default branch instead of actual default branch.What does this change mean?
This change means that repositories like cats or http4s (or any repository using multibranch) can maintain several branches updated with Scala Steward by updating the
repos.md
line to:Isn't this a breaking change?
Removing the CLI param doesn't provoke a breaking change, since a new version hasn't been released since #2183 was merged 😸.
Want to see it in action?
Here you can see this new feature in action. Steward was run with the following parameters:
with
repos.md
being:As you can see here Scala Steward created 3 PRs, each pointing to a different branch, and each one of them using the
.scala-steward.conf
present in that branch.