Use Scala script for targeted releases

[rtyley]

Here we're continuing work on:

• feature for library authors: testing library updates using Scala Steward to raise draft PRs with specified library updates scala-steward-org/scala-steward#3612)

...but switching from using bash to Scala instead.

Testing

I've made several runs using this updated script, and it's now working well.

Preventing 'unconfigured' runs of Scala Steward

Workflow Run 13 did not go as expected - when given a PR that had not generated a preview release, the script silently failed to generate a targeted-scala-steward.conf - but nothing prevented the next step from occurring, which was running Scala Steward. Consequently Scala Steward ran without any global config (including our normal config, that limits the number of PRs Scala Steward raises & groups the PRs), and raised about 20 individual PRs that it normally would not have.

In order to prevent this happening again, I've ensured that the script will return a non-zero exit code if no-config is generated, which then correctly terminates the workflow without running Scala Steward.

Blockers

• Stop using a PREVIEW version of play-git-hub - this needs the following PRs to be merged:
  • Fix creation of Test repos: replace OkHttp's ETag support with com.gu.etag-caching , adopt Cats Effect (IO) rtyley/play-git-hub#18
    • Support fetching-then-parsing-with-key etag-caching#110
      • Improved delineation of ExecutionContexts for fetching vs parsing etag-caching#111

[rtyley]

Weirdly, although the test run was mostly successful, it did do one weird thing - open 1 of the 8 PRs it raised as non-draft:

• Update pan-domain-authentication to 11.0.0-PREVIEW.sh-wsyupgrade-aws-sdk-to-2.2025-09-17T1358.a15b1789 typerighter#525 - I've put this back to draft now

https://github.com/guardian/scala-steward-public-repos/actions/runs/18164577794/job/51703329773#step:8:1831

I can not see why this would have happened...!

cc @jonathonherbert

[rtyley]

Weirdly, although the test run was mostly successful, it did do one weird thing - open 1 of the 8 PRs it raised as non-draft

I've figured out why that 1 repository got a non-draft PR - it exposed a Scala Steward bug which I'm now fixing with this PR:

• Fix: repo-config for pullRequests.draft should not be wiped when combined with _unset_ config scala-steward-org/scala-steward#3719

...basically that repo had a .scala-steward.conf with some pullRequests.xxx entries in it - but no pullRequests.draft:

https://github.com/guardian/typerighter/blob/d6461c6782a9734707166f3eb825ede28c29c20d/.scala-steward.conf#L5

...due to the bug, for pullRequests.draft being not-set took precedence over being set!

[rtyley]

The config generated here (for an sbt plugin...) looks incorrect - why is there still a Scala version in the artifact name (sbt-scrooge-typescript_2.12)?:

Wrote config to /home/runner/work/scala-steward-public-repos/scala-steward-public-repos/targeted-scala-steward.conf

updates.allow = [{"groupId":"com.gu","artifactId":"sbt-scrooge-typescript_2.12","version":"4.0.0-PREVIEW.fpdowngrade-scrooge.2025-10-02T0939.1433794d"},{"groupId":"com.gu","artifactId":"scrooge-generator-typescript","version":"4.0.0-PREVIEW.fpdowngrade-scrooge.2025-10-02T0939.1433794d"}]

updates.allowPreReleases = [{"groupId":"com.gu","artifactId":"sbt-scrooge-typescript_2.12","version":"4.0.0-PREVIEW.fpdowngrade-scrooge.2025-10-02T0939.1433794d"},{"groupId":"com.gu","artifactId":"scrooge-generator-typescript","version":"4.0.0-PREVIEW.fpdowngrade-scrooge.2025-10-02T0939.1433794d"}]

pullRequests.draft = true
commits.message = "Update ${artifactName} from ${currentVersion} to ${nextVersion}"
pullRequests.grouping = [{
  name = "guardian/scrooge-extras/pull/39",
  title = "Update `scrooge-extras` to 4.0.0-PREVIEW.fpdowngrade-scrooge.2025-10-02T0939.1433794d",
  filter = [{"group" = "*"}]
}]