pinup hat Meinungen: zwölf Entscheidungen und ihr Preis
pinup liest Renovates Konfiguration. An zwölf Stellen hat es eine feste Meinung, meist eine andere als Renovate. Nicht aus Prinzip, sondern weil in meinem Bestand jede dieser Stellen einmal Zeit oder Geld gekostet hat.
Diese Serie erklärt die Entscheidungen einzeln. Jede Folge nennt die Meinung, die Alternative, den Preis und den Anlass. Jeden Montag eine Folge, bis kurz vor Silvester.
01 — Meinungen statt Optionen
Ein Werkzeug für Dependency-Updates muss vieles offenlassen. Renovate bedient Tausende Setups, und das geht nur mit Optionen. pinup bedient zunächst eines: meinen eigenen Bestand mit rund 200 Repositories. Dort haben sich ein paar Fragen so oft gestellt, dass ich sie nicht mehr als Option wollte, sondern als Regel.
Eine Meinung im Code ist teurer als eine Option. Sie schließt Setups aus, und sie muss sich rechtfertigen. Deshalb hat jede Folge dieselbe Form:
- Die Meinung in einem Satz.
- Die Alternative, und warum sie anderswo richtig ist.
- Der Preis: was pinup deshalb nicht kann.
- Der Anlass: ein gemessener Vorfall, keine Theorie.
- Die Durchsetzung: ein Typ, ein Test oder ein Gate. Nicht Disziplin.
02 — Renovate bleibt ein großartiges Werkzeug
Das vorweg, weil die Serie sonst falsch gelesen wird. Ich habe Renovate über Jahre gern genutzt. Bei einigen Kunden läuft es weiter, und dort empfehle ich es auch weiter.
Wo pinup anders entscheidet, ist Renovates Entscheidung meist die richtige für seinen Kontext. Ein Werkzeug für alle muss tolerant sein. Ein Werkzeug für einen Bestand darf streng sein. Das ist kein Urteil über Qualität, sondern über Zuschnitt.
pinups eigene Konfiguration heißt .pinup.yaml oder .pinup.jsonc (auch .yml oder .json). Eine vorhandene renovate.json liest pinup trotzdem, ebenso renovate.json5, .renovaterc und .renovaterc.json im Wurzelverzeichnis. Der Grund: Ein Umstieg soll in keinem Repository ein Byte ändern. Wer wechselt, muss vorher nichts umbenennen, und wer zurückwechselt, auch nicht. Konfigurationen unter .github/ oder .gitlab/ liest pinup allerdings nicht, die müssen einmal umziehen. Nur zwei Konfigurationsdateien zugleich lehnt pinup ab, statt still eine zu wählen.
Aus demselben Grund bleiben Branch-Namen und # renovate:-Annotationen dieselben. Dazu gibt es eine eigene Folge.
03 — Die zwölf Meinungen im Überblick
| Termin | Meinung | Worum es geht |
|---|---|---|
| 12.10.2026 | Nichts passiert ohne Grund | Jedes zurückgehaltene Update nennt Grund, Regel und Zeitpunkt. |
| 19.10.2026 | Ein Gate, das nie rot war, ist keins | Mutationstests für die Prüfungen. |
| 26.10.2026 | Nicht verfolgt ist keine Lücke | Was nichts aktualisiert, und was so bleiben darf. |
| 02.11.2026 | Der Kern entscheidet, Plugins führen aus | Plugins bekommen keine Zugangsdaten und nur ihren Ausschnitt. |
| 09.11.2026 | Kompatibel, wo es Nutzer schützt | Konfiguration, Branch-Namen und Annotationen bleiben die von Renovate. |
| 16.11.2026 | Das strengere Label gewinnt | Die gemessene Änderung zählt, nicht nur die Versionsnummer. |
| 23.11.2026 | Kein Byte ohne Plan | Jeder Lauf schreibt zuerst einen maschinenlesbaren Plan. |
| 30.11.2026 | Bytes statt Bäume | Eine Änderung ist ein Byte-Bereich. YAML und JSON werden nie neu serialisiert. |
| 07.12.2026 | Konfiguration mit Herkunft | Jeder Wert weiß, welche Quelle ihn gesetzt hat. |
| 14.12.2026 | Langweilige Abhängigkeiten | Zwei direkte Fremdbibliotheken. GPG bewusst nicht nachgebaut. |
| 21.12.2026 | Das Werkzeug aktualisiert sich selbst | Dogfooding als Kriterium für jedes Release. |
| 28.12.2026 | Zurückgezogen ist nicht gelöscht | Verwundbare eigene Versionen verlassen automatisch den Umlauf, ohne gelöscht zu werden. |
Die Termine gelten, solange nichts Dringenderes dazwischenkommt. Eine CVE-Welle hat hier Vorrang. Die Links funktionieren ab dem jeweiligen Termin.
Begriffe, die öfter vorkommen
- Bestand: die rund 200 Repositories, die ich betreibe und die pinup aktualisiert.
- Runner: das Repository mit dem geplanten CI-Job, der pinup über alle Repositories laufen lässt. Dort liegt auch die zentrale Konfiguration, die alle anderen erweitern.
- Shadow-Modus: Vor der Umstellung lief pinup neben Renovate. Es schrieb nichts und verglich seine Pläne mit den Merge-Requests von Renovate.
- Fast-Lane: ein gezielter Lauf, sobald eines meiner eigenen Pakete ein Release hat. Er geht nur in die Repositories, die das Paket nutzen.
- Golden-Tests: Tests, die das Ergebnis eines Laufs mit einer geprüften, abgelegten Erwartung vergleichen. Die Erwartung wird nie automatisch neu geschrieben.
- Wolfi: eine Linux-Distribution für Container-Images. Daraus baue ich die Pakete für meine eigenen Images.
Häufige Fragen
Ist die Serie eine Abrechnung mit Renovate?+
Nein. Renovate ist die Referenz, an der pinup gemessen wird, und bei einigen Kunden weiter meine Empfehlung. Jede Folge nennt die Alternative und erklärt, warum sie in anderen Setups richtig ist. Die Serie beschreibt einen anderen Zuschnitt, kein besseres Werkzeug.
Brauche ich pinup, um etwas davon zu haben?+
Nein. Die meisten Entscheidungen lassen sich auf jedes Werkzeug übertragen, auch auf eine eigene Renovate-Konfiguration. Ein zurückgehaltenes Update ohne Grund ist ein Fehler, egal welches Werkzeug es zurückhält. Ein Gate, das nie rot war, prüft nichts, egal in welcher Pipeline es steht.
Wo finde ich pinup?+
Code, Releases und Dokumentation liegen auf GitHub, unter Apache-2.0. Die Projektseite hat einen Quickstart und die Kapitel zu Konfiguration, Plan und Sicherheit.
Fazit
Zwölf Entscheidungen, zwölf Preise. Die Serie beginnt am 12. Oktober mit der Meinung, die pinup überhaupt erst nötig gemacht hat: Nichts passiert ohne Grund.
Den Anlass für pinup erzählt der Beitrag zum Umstieg. Code und Dokumentation liegen auf GitHub, eine Übersicht auf der Projektseite zu pinup.
Welche dieser Entscheidungen zählen für dein Setup? Ich sehe mir deine Konfiguration an.
Ein Blick auf deine Renovate- oder pinup-Konfiguration mit pinup advise: was sie nicht liest, was sie doppelt sagt und welche Updates still liegen bleiben.
Über den Autor
Kai Ole Hartwig
Programmiert seit 2002 – autodidaktisch gelernt, 2012 mit KO-Web selbständig gemacht. Über 100 Projekte, Fokus auf Security, Performance, Automatisierung und Qualität. Heute freiberuflich: DevSecOps-Beratung, Schulungen und Softwareentwicklung.