Scala Steward

Automatisierte Dependency-Updates für JVM Projekte

Worum geht es?

Unsere Software hat Abhängigkeiten
Abhängigkeiten sollten aktuell bleiben
diese Arbeit ist aufwändig und langweilig

Wir benutzen in unserer Software natürlich Bibliotheken oder Abhängigkeiten, um Funktionalität zu erhalten, die jemand anderes bereits entwickelt hat.
Diese Abhängigkeiten sollten aktuell bleiben, um Risiken durch eventuelle Sicherheitslücken zu minimieren und den Wartungsaufwand beim Updates kleinzuhalten. Denn je länger man ein Update aufschiebt, umso größer kann der Aufwand werden auf die neue Version zu wechseln.
Aber das Aktualisieren ist umständlich und langweilig, denn
- ... man muss herausfinden welche Abhängigkeiten aktualisiert werden können
- ... wie die neue Versionsnummer lautet
- ... wo sich die Release Notes befinden, um herauszufinden, welche Auswirkungen das Update auf die eigene Software haben wird
- ... dann die Versionsnummer im Build hochziehen
- ... und das Update testen

Beispiel

https://github.com/akka/akka/pull/32591

Inhalt

Features
Zahlen & Fakten
Historie & Implementierung

Features

In dem Diagramm sind existierende Versionsnummern einer fiktiven Bibliothek dargestellt. Und die Pfeile stellen Pull-Requests dar, die der Steward erstellen würde.

D.h. erst schlägt er vor auf die neuste Patch-Version zu gehen

Wenn die Patch-Version nicht mehr hochgezogen werden kann, schlägt er vor auf die neueste Minor-Version zu gehen

Wenn die Minor-Version nicht mehr hochgezogen werden kann, schlägt er vor auf die neueste Major-Version zu gehen

Die Idee dahinter ist erst kleine Versionssprünge zu bevorzugen, da diese wahrscheinlich mit geringerem Aufwand gemerged werden können

Unterstütze Build Tools

Gradle
Maven
sbt
Mill
Scala CLI

Maven

pom.xml

<hikari.version>6.2.1</hikari.version>
...
<dependency>
  <groupId>com.zaxxer</groupId>
  <artifactId>HikariCP</artifactId>
  <version>${hikari.version}</version>
</dependency>

Gradle

gradle/libs.versions.toml

[versions]
apache-poi = "5.4.0"

[libraries]
apache-poi = { module = "org.apache.poi:poi",
               version.ref = "apache-poi" }

sbt

build.sbt

libraryDependencies ++= Seq(
  ...
  "org.postgresql" % "postgresql" % "42.7.5",
  ...
)

Mill

build.mill

def ivyDeps = Agg(
  ...
  ivy"activemq:activemq:4.0-M3",
  ...
)

Unterstütze Git Forges

GitHub
GitLab
Bitbucket Cloud und Server
Forgejo / Gitea
Azure Repos

Konfiguration pro Instanz / Repo

.scala-steward.conf

updates.pin = [
  { groupId = "com.oracle.database.jdbc",
    artifactId = "ojdbc8", version = "19." }
]

commits.message =
  "bump: ${artifactName} ${nextVersion} (was ${currentVersion})"

pullRequests.frequency = "@monthly"

Um das Verhalten des Stewards an seine Bedürfnisse anzupassen, kann man es pro Instanz oder pro Repo konfigurieren.

Die Konfiguration pro Instanz gilt für alle Repos, die von dieser Instanz aktuell gehalten werden. D.h. damit lassen Defaults einstellen, die den Repos überschrieben werden können.

Hier habe eine Beispielkonfiguration zusammengestellt,

die ojdbc8 auf eine Version pinnt, die mit "19." beginnt. D.h. es werden nur Updates erstellt bei denen die Major auf Version 19 bleibt.
die Überschriften der PRs und Commit-Beschreibungen ändert
und die das Intervall für neue PRs vorgibt. Standard ist PRs so schnell wie möglich zu erstellen.

Artefakt-Migrationen

Umbenennung von groupId und/oder artifactId

Jetzt kommen wir zu den Features, bei denen mehr als nur die Versionsnummer umgeschrieben wird.

Da gibt es zum einen die Artefakt-Migrationen, die groupId und/oder artifactId umbenennen können. Was z.B. nützlich ist, wenn sich der Maintainer eines Projekts ändert

In dem Beispiel hier haben wir den Diff eines Pull-Requests, der die Version des Plugins sbt-pgp hochzieht und gleichzeitig die groupId umschreibt.

Diese Artefakt-Migrationen werden in einer Konfigurationsdatei definiert. Dabei gibt es eine globale Datei, die von allen Instanzen geladen wird, aber man kann auch pro Instanz eine eigene Datei vorgeben und somit z.B. nicht öffentlich Artefakte umschreiben.

Jetzt kommen wir zu den Features, bei denen mehr als nur die Versionsnummer umgeschrieben wird.

Da gibt es zum einen die Artefakt-Migrationen, die groupId und/oder artifactId umbenennen können. Was z.B. nützlich ist, wenn sich der Maintainer eines Projekts ändert

In dem Beispiel hier haben wir den Diff eines Pull-Requests, der die Version des Plugins sbt-pgp hochzieht und gleichzeitig die groupId umschreibt.

Post-update hooks

Ausführung beliebiger Programme nach einem Update

Des Weiteren gibt es post-update hooks mit denen beliebiger Programme nach dem Update ausgeführt werden. Und alle Änderungen, die diese Hooks produzieren werden von Scala Steward committed und sind Teil des Pull-Requests.

Dieses Feature eignet sich z.B. für Dateien, die von Build Tool Plugins generiert werden oder für Quelltext-Formatierer

Das Beispiel hier zeigt ein Update von Scalafmt, was ein Formatierer für Scala Code ist. Neben dem Aktualisieren der Versionsnummer gibt es hier auch Änderungen der Formatierung in dieser Dependencies.scala-Datei.

Zusätzlich wurde der Commit aus dem post-update hook in die .git-blame-ignore-revs aufgenommen, was dazu führt, dass diese Änderungen durch den Hook bei git blame nicht angezeigt. Ob Commits in diese Datei aufgenommen kann man pro post-update hook konfigurieren.

Die Hooks kann man übrigens in der Konfiguration selber definieren.

Dieses Feature eignet sich z.B. für Dateien, die von Build Tool Plugins generiert werden oder für Quelltext-Formatierer

Die Hooks kann man übrigens in der Konfiguration selber definieren.

Scalafix-Migrationen

Umschreiben des Quelltexts an neue Version

Das letzte Feature, dass ich vorstelle, ist für mich zugleich eines der coolsten Features in Scala Steward überhaupt. Und das sind die Scalafix-Migrationen, die den Quelltext des Projekts an die neue Version anpassen kann.

Das ganze basiert auf dem Scalafix Tool mit dem Programme schreiben kann, die Quelltext umschreiben. Im Scala Steward kombinieren wir diese Fähigkeit mit Metadaten bei welchem Versionssprung eine bestimmte Scalafix-Regel ausgeführt werden soll.

Hier ist ein Beispiel-Pull-Request bei dem eine Scalafix ausgeführt wurde. In dem ersten Commit sehen welches Scalafix ausgeführt wurde und weiterführende Dokumentation über diesen Scalafix. Und der zweite Commit beinhaltet das übliche Hochziehen der Version.

scalafix-migrations.conf

Zahlen & Fakten

Community

mehr als 6250 Commits
... seit September 2018
... von 119 Personen

Öffentliche Instanz

betrieben von 2018 bis 2022 von mir;
seit 2022 von VirtusLab
hat bis zu 2400 Projekte aktualisiert
> 429.000 erstellte PRs
> 237.000 zusammengeführte PRs

Kommerzielle Nutzung

> 2.500.000 Downloads des Docker Image
40 Unternehmen gelistet in README
(darunter Zalando, Spotify, Guardian, Avast, Springer Nature, ...)

Neben der öffentlichen Nutzung wird der Scala Steward aber auch privat oder kommerziell verwendet. Es liegt aber in der Natur der Sache, dass es schwierig ist herauszufinden wie weit hier die Verbreitung ist.

Wir haben 2,5 Millionen Downloads des Docker Images. Das klingt viel, aber man muss beachten, dass bei jedem Commit ein neues Image gebaut wird und damit jede nicht öffentlich Instanz mehrere Downloads verursacht.

Eine grobe Abschätzung ist die Anzahl Downloads durch die Anzahl der Commits zu teilen, womit wir auf etwa 400 Instanzen kommen würde. Außerdem haben 40 Unternehmen in der README bekundet, dass sie Scala Steward einsetzen. Ich vermute, die Wahrheit liegt irgendwo dazwischen.

Bei uns

seit September 2020
11 Projekte
122 MRs auf GitLab
3189 PRs auf Bitbucket

Historie & Implementierung

Wie alles begann

Aufsatz auf sbt-updates Plugin
daher nur für sbt-Projekte
PRs nur auf GitHub
aufgebohrter Regex zum Ersetzen
von Versionsnummern

Stand heute

Batch-Prozess
1. Dependencies extrahieren
2. neue Versionen ermitteln
3. Versionsnummern suchen und ersetzen
4. PR erstellen
Caches everywhere: Repos, Versionen, PRs

Ausblick

Dependencies via Build Server Protocol (BSP) extrahieren

Hier noch ein kurzer Ausblick wie sich Scala Steward in Zukunft verändern könnte.

Es gibt das Build Server Protocol, was die Unterstützung von Build Tools in IDEs vereinfachen soll. Mit dem BSP können IDEs ohne großen weitere Anpassungen Build Tools unterstützen, wenn auch diese das BSP implementieren.

Und eigentlich ist das BSP dafür gedacht Code zu kompilieren, auszuführen oder Tests laufen zu lassen. Aber es gibt auch die Möglichkeit Dependencies über das BSP abzufragen und daher könnte der Scala Steward ein BSP-Client sein und somit weitere und ohne großen Aufwand alle jetzigen oder zukünftigen BSP-fähigen Build Tools unterstützen.

Scala Steward automatisiert Dependency-Updates
... unterstützt viele JVM Build Tools und Git Forges
... kann vielseitig konfiguriert werden
... hat noch Kapazitäten frei für eure Projekte!

github.com/scala-steward-org/scala-steward