Update sbt-ci-release to 1.11.0

[scala-steward]

About this PR

📦 Updates com.github.sbt:sbt-ci-release from 1.9.3 to 1.11.0

📜 GitHub Release Notes - Version Diff

Usage

✅ Please merge!

I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.

If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.

Configure Scala Steward for your repository with a .scala-steward.conf file.

Have a fantastic day writing Scala!

⚙ Adjust future updates

Add this to your .scala-steward.conf file to ignore future updates of this dependency:

updates.ignore = [ { groupId = "com.github.sbt", artifactId = "sbt-ci-release" } ]

Or, add this to slow down future updates of this dependency:

dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.github.sbt", artifactId = "sbt-ci-release" }
}]

^{labels: sbt-plugin-update, early-semver-minor, semver-spec-minor, commit-count:1}

[saeltz]

@mccartney, do you have sufficient permissions to do the change for publishing to Sonatype Central? The existing method won't work anymore after June 30th.

[mccartney]

I likely do not. I haven't migrated any other project yet. But for Scapegoat I don't have the credentials to Sonatype.
I am not sure what exactly is needed to set up the new way. I.e. if we need to ask @sksamuel or are we good on our own.

[saeltz]

We at least need to change environment variables of GitHub Actions to update this plugin. Do you have access to that?

[mccartney]

I don't have it either.

[Johnnei]

I think the credentials that were set in #851 should already work for the new central portal.
So we might be able to fix it by reassigning env vars during the script, but haven't tried any project either yet (most of my sbt stuff publishes to private registries)

[Johnnei]

Tried a few things scapegoat-scala/sbt-scapegoat#227, but it does seem that the credentials don't work for Central Portal (I got confused with me changing the host in the last change).
I guess we need Sam to initiate the Central Portal migration for his namespaces (if he didn't already) and set new token in the env vars (which sbt still seems to use).

[scala-steward]

Superseded by #962.

[Johnnei]

@sksamuel Any guidance on how we can unblock Scapegoat after the Sonatype Central migration?

[Johnnei]

@saeltz @mccartney as it doesn't seem like we're getting a hold of @sksamuel , if you guys are still willing to maintain scapegoat maybe it's time to stop relying on Sam's credentials and switch to use one of our namespaces (https://central.sonatype.org/register/namespace/#github-namespaces)?

[mccartney]

Not an easy decision, but let's do that.
I understand the consequence is that we need to switch the group-artifact pair to something new. And people will need to manually update it.

[saeltz]

I don't have any Scala 2 codebases running anymore and as such Scapegoat in its current form doesn't help me a lot. I'd rather put my efforts into porting the remaining rules to https://github.com/dedis/scapegoat-scalafix as @t1b00 suggested in #868 to make it usable for Scala 3. Even if that has some limitations as well.

[Johnnei]

As new scala versions are dripping out, I've started to publish under org.johnnei.scapegoat from my fork on GitHub (and as I prefer GitLab CI on my gitlab instance too https://git.johnnei.org/scapegoat): https://repo1.maven.org/maven2/org/johnnei/scapegoat/

As I (sadly) still have plenty of Scala 2.12/2.13 repos to maintain, I simply have a need to at least keep up with the compiler releases to not lose the static analysis my teams have gotten used to.