Comments (14)
I work in many repos that have multiple active branches: in the Scala org (Scala itself, some of the module repos, etc), in the Lightbend org, and more generally in the course of my work on the Scala community build
as others have observed, there's really two pieces to this, one is the ability to pick a branch that isn't the GitHub default branch, the other is the ability to pick multiple branches
re: a non-default branch, sometimes the default branch isn't the most useful branch for scala-steward to target. in repos that do merges from older branches to newer branches, the best branch for scala-steward to target might be the oldest actively maintained branch. (why wouldn't that be the default branch, you might wonder? because the default branch is where new development takes place. but things like Scala version bumps, sbt version bumps, and testing library bumps aren't really new development) admittedly there is an obvious failure mode: if you only target the oldest branch, then you miss updates to dependencies that the oldest branch doesn't have. but the current scheme has an obvious failure mode too, which is that your older branches don't benefit from the steward at all.
re: multiple branches, I agree with Frank that just treating the branches separately would be a perfectly good initial starting point. some repos don't do regular merges (or any merges) from older branches to newer branches, and in those cases, the simple strategy would be fine. even in repos that do merge between branches, the simple version of the feature still wouldn't be terrible. maintainers could either 1) manually close redundant PRs, or 2) go ahead and merge redundant PRs and then sort out any merge conflicts at merge-forward time (and in many cases there wouldn't be any conflict, since git would notice that the change was already made)
from scala-steward.
I am currently implementing it following @fthomas's proposition posted on Gitter. I'll make a PR soon enough :)
from scala-steward.
@kbreidenbach perhaps it will be enough for you to simply change the default branch in your repo? I don't think steward hardcodes "master", I think it goes off the default-branch setting
from scala-steward.
#2281 made branch selection also available for users of the public Scala Steward instance, thanks to @alejandrohdezma! https://github.com/scala-steward-org/scala-steward/blob/master/docs/faq.md#can-scala-steward-update-multiple-branches-in-a-repository shows how the repos.md
file needs to be updated to select a different branch or how to add multiple branches.
from scala-steward.
Should support multiple watched branches, maybe something like["akka2.4","master"]
from scala-steward.
How would multiple branches work? Would it submit a PR to each branch, and let the maintainers pick which PR to merge? Try to be smart about picking the first branch?
I have a similar use case. Just thinking about how it would work.
from scala-steward.
I don't maintain multiple branches in my projects so I don't have an intuition what would work best in such cases. A PR for each branch sounds like a simple strategy which could be refined with more practical experience of this feature.
from scala-steward.
A good first step would be to support choosing from which branch to checkout and create the PR to, defaulting to Master.
I don't think that creating multiple Prs for a single update would be helpful especially if CI pipelines are costly (time or resources)
from scala-steward.
shapeless would also benefit from this. There are two active development branches, master
and shapeless-3
. Scala Steward only targets the former ... it'd be great if it could update both.
from scala-steward.
We could use this as well at Datalogue.
Here is how we manage our projects.
Each is using master
as the state of the latest release that's the default branch.
We then have release branches that follow the pattern release-x.x.x
that enable us.
Ideally for us the ideal behavior would be that for each release-x.x.x
branch the scala steward would go try to make the update and PR against that branch
In the case mentioned by @rossabaker, if one of the several PRs for the same version update gets merged, I imagine we could have the bot close the sister PRs automatically. Since a user might want to merge and update in upstream or downstream.
Hope this helps
from scala-steward.
Any news on the PR as we are trying to move away from the use of master
as the trunk and would like a way to pick the branch name for scala steward to check for updates?
from scala-steward.
Closing as resolved.
My understanding is #2183 implemented branch selection feature.
Thanks @alejandrohdezma
from scala-steward.
This change will be available for users of the Scala Steward GitHub Action, once scala-steward-org/scala-steward-action#268 is merged. Allowing this in any other way (either repos.md
or .scala-steward.conf
) would involve a bigger refactor in Scala Steward.
from scala-steward.
Reopening because #2183 adds branch selection for users of the GitHub Action but not for users of the public Scala Steward instance.
from scala-steward.
Related Issues (20)
- No able to create a pull request Bitbucket HOT 1
- sbt not found with scala-steward-action HOT 1
- no effect with .github/.scala-steward.conf override if PRs has been already created before HOT 2
- Scala Steward run within an org is incorrectly creating PR's against wrong repo HOT 3
- [Bug?] Cannot resolve -p with Mill 0.11.6 HOT 8
- Option to abort on scalafix migration failure HOT 1
- Using custom dependency rules for scalafix-migrations with 'type: "build"'
- Scala Steward runs as root when using the published Docker image (but it probably shouldn't)
- Unable to respect update frequency when version number is stored as a val
- Scala Steward attempting to raise PRs for group branches that already have PRs HOT 3
- Force-pushing over modified branches HOT 5
- Avoid pushing scala updates for non LTS versions HOT 6
- Automatic `buildRoots` detection
- Bitbucket repository name is malformatted in URL
- Clarification of "updatePullRequests" for grouped PRs HOT 4
- Feature to limit branch name length HOT 3
- Wrong targetRefName when create azure-repo PullRequestPayload
- Config option to update files only in defined paths
- Scalafmt cannot run when buildRoots is set
- `scala-cli` dependencies: "WARN Unable to bump version for update [...]"
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from scala-steward.