Allow choosing a custom default branch

[alejandrohdezma]

What has been done in this PR?

A new --default-branch argument has been added to the Scala Steward cli. When this argument is present, its value will be used as the default branch when updating repositories instead of the repository's default branch.

Why this change?

This change enables users who run their own instances of Scala Steward to customize the branch in which updates are performed. This will enable multiple use-cases, for example:

• Updating multiple branches in a repository.
• Merging updates into a "develop" branch regularly that will be merged into the real default branch every so often.

This change will be specially useful for users of the Scala Steward GitHub Action after scala-steward-org/scala-steward-action#268 is merged.

Example:

on:
  schedule:
    - cron: '0 0 * * 0'
name: Launch Scala Steward on `main`, `1.x` and `2.x`
jobs:
  scala-steward:
    runs-on: ubuntu-latest
    name: Launch Scala Steward
    strategy:
      matrix:
        branch: ['main', '1.x', '2.x']
    steps:
      - name: Launch Scala Steward
        uses: scala-steward-org/scala-steward-action@v2
        with:
          github-token: ${{ secrets.REPO_GITHUB_TOKEN }}
          branch: ${{ matrix.branch }}

[codecov]

Codecov Report

Merging #2183 (1451b1d) into master (c652507) will decrease coverage by 0.27%.
The diff coverage is 69.23%.

@@            Coverage Diff             @@
##           master    #2183      +/-   ##
==========================================
- Coverage   78.18%   77.91%   -0.28%     
==========================================
  Files         131      135       +4     
  Lines        2251     2291      +40     
  Branches       60       60              
==========================================
+ Hits         1760     1785      +25     
- Misses        491      506      +15     

Impacted Files	Coverage Δ
.../scala/org/scalasteward/core/application/Cli.scala	96.15% <ø> (ø)
...org/scalasteward/core/repocache/RepoCacheAlg.scala	0.00% <0.00%> (ø)
...n/scala/org/scalasteward/core/vcs/VCSRepoAlg.scala	92.30% <50.00%> (-7.70%)	⬇️
...ala/org/scalasteward/core/application/Config.scala	97.43% <100.00%> (+0.06%)	⬆️
...in/scala/org/scalasteward/core/vcs/VCSApiAlg.scala	100.00% <100.00%> (ø)
.../main/scala/org/scalasteward/core/git/Branch.scala	75.00% <0.00%> (-25.00%)	⬇️
...org/scalasteward/core/buildtool/mill/MillAlg.scala	86.95% <0.00%> (-3.96%)	⬇️
.../main/scala/org/scalasteward/core/io/package.scala	100.00% <0.00%> (ø)
...scala/org/scalasteward/core/scalafmt/package.scala	100.00% <0.00%> (ø)
...scala/org/scalasteward/core/update/UpdateAlg.scala	100.00% <0.00%> (ø)
... and 16 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c652507...1451b1d. Read the comment docs.

[ChristopherDavenport]

I wonder if there is a way we could adjust it to do multiple passes if branches were set via the .scala-steward.conf file. I know its not a simple hop from here to there, but then it would make sense that projects might set this and then steward could run and help when repositories are in cross-branching situations.

Almost all open source projects multi-branch at some point in their project lifecycles.

@fthomas do you think that would be feasible?

[alejandrohdezma]

I wonder if there is a way we could adjust it to do multiple passes if branches were set via the .scala-steward.conf file. I know its not a simple hop from here to there, but then it would make sense that projects might set this and then steward could run and help when repositories are in cross-branching situations.

Almost all open source projects multi-branch at some point in their project lifecycles.

@fthomas do you think that would be feasible?

I run through this idea over the weekend without success. I don't see a way of allowing this kind of configuration from the .scala-steward.conf that doesn't involve a complete refactor of how Scala Steward operates, given that Steward creates and searches caches based on the commit hash from the default branch before cloning the repository (and thus reading the configuration).

Given all that, I strongly believe that this solution is the best one that involves minimal changes, and allow branch selection for a wide range of Scala Steward users.

Of course, please @fthomas correct me if I'm wrong 😸

[alejandrohdezma]

Hey @exoego, any chance we could have this reviewed? This is a feature several libraries could benefit from. I've used this version for the past few weeks, and it works like a charm. It creates PRs on several branches, while remembering which ones have been closed on which specific branch, and allows using different .scala-steward.conf per-branch.

[exoego]

@alejandrohdezma Thanks for this PR 👍
I will review on this weekend.

[exoego]

@alejandrohdezma
Code LGTM 💯

Could you also update the list of CLI arguments in https://github.com/scala-steward-org/scala-steward/blob/master/docs/help.md 🙏

[alejandrohdezma]

@alejandrohdezma Code LGTM 💯

Could you also update the list of CLI arguments in https://github.com/scala-steward-org/scala-steward/blob/master/docs/help.md 🙏

Done here :)

[exoego]

LGTM

[exoego]

I am going to merge this, since this is great addition and changes LGTM.
If any issues found later, I am fine to fix/revert.