Nicht verfolgt ist keine Lücke

01 — Die Meinung in einem Satz

Was nichts aktualisiert, gehört aufs Dashboard, außer das Repository sagt, dass es so bleiben soll.

Mit --coverage durchsucht pinup nach dem Plan den Checkout. Es sucht zwei Formen: Image-Referenzen mit Pfad und Variablen wie HELM_VERSION, jeweils mit einer dreiteiligen Version. Was kein Manager gelesen hat, steht im Plan und im Dependency-Dashboard unter „Not updated by anything“.

Eine Version, die bewusst stehen bleibt, markiert man:

services:
  legacy:
    # pinup: coverage-ignore
    image: example/tool:1.4.2

Alles andere bekommt eine Annotation und wird damit ein normaler Kandidat für Updates. Welche Dateien pinup gar nicht durchsuchen soll, steht in den ignorePaths der .pinup.yaml oder einer vorhandenen renovate.json.

02 — Die Alternative: den Managern vertrauen

Renovate aktualisiert, was seine Manager finden. Für alles andere schreibt man einen eigenen Regex-Manager. Das ist ein klarer Vertrag: Das Werkzeug rät nicht, und was es meldet, stimmt.

Dieser Vertrag ist richtig für ein Werkzeug, das in Tausenden Repositories läuft. Eine Suche, die rät, erzeugt Rauschen, und Rauschen in Tausenden Dashboards ist schlimmer als eine Lücke. Nur: Wer den Regex-Manager nie geschrieben hat, erfährt auch nie, dass er fehlt.

03 — Der Preis

Eine Suche, die raten muss. Ohne Manager weiß pinup nicht, was eine Zeichenkette bedeutet. Deshalb sucht es nur zwei Formen, die sich als präzise erwiesen haben. Einen Pin wie name@1.2.3 oder eine Version in einer URL findet es nicht.

Zweiteilige Versionen bleiben außen vor. Tags wie valkey:8.1-alpine oder Variablen wie PHP_VERSION: "8.5" wählen eine Linie, deren Patches sie ohnehin folgen. Eine neue Linie ist eine Entscheidung, kein Update. Das ist meistens richtig und manchmal nicht.

Markierungen im Code. Wer bewusst pinnt, muss das hinschreiben. Das ist eine Zeile mehr, aber sie sagt auch dem nächsten Menschen, dass der Pin Absicht ist.

04 — Der Anlass

Am 25. September 2026 habe ich zehn Repositories meines Bestands durchsucht. 774 Versionen standen darin. 374 davon kannte der Plan, 27 standen unter einer Annotation, 6 in Lock-Dateien, 141 waren Rauschen. Blieben 226 Kandidaten.

173 davon waren keine Lücke

173 der 226 lagen in einem einzigen Repository: meinen Wolfi-Paketen. Keine davon war eine Lücke. Der größte Teil gehört zu Upstream-Rezepten, die ich aufbewahre, aber nicht baue. Ihre Versionen veralten mit Absicht. Hätte pinup sie als Lücken gemeldet, hätte das Dashboard gelogen. Daher der Titel dieser Folge und die Markierungen.

Die echten Lücken

Von den restlichen 53 habe ich jede von Hand geprüft. Etwa 22 waren echte Pins, die nichts aktualisierte:

• Images in Compose-Dateien, weil kein Manager sie las,
• die Images in einer lefthook.yml, die aus einer Vorlage in jedes Repository kopiert wurde,
• Werkzeug-Versionen in CI-Variablen ohne Annotation,
• Annotationen, die kein Manager las, weil ihre Form nicht zu ihm passte: ein fehlendes versioning=, eine Zuweisung im Shell-Stil, einfache statt doppelter Anführungszeichen.

Die meisten sind inzwischen behoben: mit Annotationen, einem Manager für lefthook.yml in der Runner-Konfiguration und einem für Compose-Images.

05 — Die Durchsetzung

• Jede Ausnahme hat einen Test. Kommentare, Prosa, Tests, gesperrte Pfade, Markierungen, zweiteilige Tags: Für jede Ausnahme gibt es einen Fall, der ruhig bleiben muss. Daneben stehen Fälle, die melden müssen.
• Brüche für die Abdeckung. Sechs Mutationen prüfen unter anderem, dass die Markierung wirkt, dass das Dashboard den Abschnitt zeigt, dass --coverage etwas tut und dass advise --init seine eigenen Prüfungen besteht.
• Plan und Checkout sind selten derselbe Stand. Hat pinup einen Pin gerade erst angehoben, kennt der Plan noch den alten Wert. Eine Zeile, die den Namen einer bekannten Abhängigkeit trägt, gilt deshalb als verfolgt. Das kam aus einem Fehlalarm im eigenen Bestand.

Für neue Repositories

pinup advise --init schlägt für ein Repository ohne Konfiguration eine erste .pinup.jsonc vor. Findet es Pins, die kein Manager liest, gehört ein Annotations-Manager für genau diese Dateien dazu, samt der Annotation für jeden Pin. Der Vorschlag muss dabei die eigenen Prüfungen von advise bestehen.

Fazit

Was kein Manager liest, veraltet still. pinup macht es sichtbar, dort, wo die Verantwortlichen lesen. Aber es unterscheidet: Eine Version, die bewusst steht, ist keine Lücke, und ein Repository darf das sagen.

Nächste Woche geht es um die Grenze zwischen Entscheidung und Ausführung: Der Kern entscheidet, Plugins führen aus. Die Übersicht aller Teile und die Begriffe, die öfter vorkommen, stehen im Auftakt der Serie.