feature for library authors: testing library updates using Scala Steward to raise draft PRs with specified library updates

[rtyley]

At the Guardian, we publish over 40 Scala software libraries, some which are general-purpose (eg. etag-caching, redirect-resolver), some quite Guardian-specific (eg. content-api-scala-client). We have dozens of development teams, and don’t use a single monorepo (we have 200 active Scala repos, over half of which are open-source), but instead many interlinked library dependencies - teams expose libraries to other teams.

When I'm changing a library that many Guardian repositories depend upon, I'd often like to know how deeply it affects them - of the 20 or so services using the library, which ones will break, and how? Will their CI fail? To find that out I need to release a preview version of the library (which I do using gha-scala-library-release-workflow), then raise 20 draft PRs, updating the artifact version in each repo, to trigger it's CI.

Scala Steward has a very good engine (NurtureAlg) for working out what artifacts a repo uses, updating artifact versions in arbitrary build files (EditAlg) and raising PRs (PullRequestRepository) - I would just like to be able to tell it what specific artifact update to roll out, rather than let it choose!

My ideal workflow would be something like invoking our existing scheduled Scala Steward workflow manually, but passing in workflow_dispatch inputs that let me specify which artifact and version I want updated. Then Scala Steward would raise PRs (only within my organisation, where our Scala Steward is authorised to run!) in draft, and ideally output a list of convenient links to each PR.

I realise this is a use case that might apply to a relatively small number of organisations - but I wonder if it would be possible to work on changes to Scala Steward that are relatively un-obtrusive that facilitate this workflow?

[fthomas]

Except the draft part, this may be already possible by using an instance-wide repo config via --repo-config and updates.allowPreReleases.

[alejandrohdezma]

Hey @rtyley, I do something like this in the workflow I use for my libraries. I just add an extra-options that I append to my .scala-steward.conf before running Steward.

That could be for example 👇🏼 if I only want to update SBT across my projects:

updates.allow = [{ groupId = "org.scala-sbt", artifactId = "sbt", version = "1.10.11" }]

Here is an example of me running the workflow using the previous "extra-option". It created the following PRs:

• Dependency Updates alejandrohdezma/sensitive-strings#274
• Dependency Updates alejandrohdezma/sbt-github#544
• Dependency Updates alejandrohdezma/sbt-fix#353
• Dependency Updates alejandrohdezma/sbt-ci#382
• Dependency Updates alejandrohdezma/sbt-mdoc-toc#316
• Dependency Updates alejandrohdezma/sbt-scalafmt-defaults#286
• Dependency Updates alejandrohdezma/sbt-scalafix-defaults#280
• Dependency Updates alejandrohdezma/sbt-modules#227
• Dependency Updates alejandrohdezma/http4s-munit#332
• Dependency Updates alejandrohdezma/alejandrohdezma#286
• Dependency Updates alejandrohdezma/sbt-yourkit#125
• Dependency Updates alejandrohdezma/tapir-anyof#137
• Dependency Updates alejandrohdezma/tapir-golden-openapi-munit#111
• Dependency Updates alejandrohdezma/sbt-propagate#47
• Dependency Updates alejandrohdezma/sbt-scripted-munit#40
• Dependency Updates alejandrohdezma/alfred4s#12
• Dependency Updates alejandrohdezma/dummy#53
• Dependency Updates alejandrohdezma/circe-munit#1

But you're not limited with just that, you could also automatically add a pullRequests.grouping to that so generated PRs use a specific branch name that you can add to your CI for monitoring, auto-merging, whatever.

[rtyley]

Here is an example of me running the workflow using the previous "extra-option".

Wow, this is great stuff! Thank you so much for sharing. This all looks amazing. I need some time to try it out - and unfortunately I'm coming down with a cold right now - but will report back here when I get something working.