Halber Sieg: Warum ich Renovates PHP/Composer-Installation nur zur Hälfte von GitHub lösen konnte

01 — Der naheliegende Schritt: einfach wiederholen, was letztes Mal funktioniert hat

Renovate installiert php und composer zur Laufzeit über containerbase, das vorgebaute Tarballs von github.com/containerbase/*-prebuild herunterlädt. GitHub ist IPv4-only und unter Last unzuverlässig — ein schlechter Nachmittag dort reichte, um jeden geplanten Scan über einen Composer-Download rot werden zu lassen. Lehrbuchfall. Also die Prebuilds in die eigene Registry spiegeln, containerbase auf den Mirror zeigen lassen, fertig — genau wie bei den Providern.

Zwei Dinge weigerten sich sofort, genauso zu laufen wie bei den Providern.

02 — Erste Komplikation: Das sind keine Artefakte, das sind Dateien

Provider wurden bei mir zu OCI-Artefakten in der Container-Registry — die Registry spricht OCI, also passten sie. containerbase tickt simpler und zugleich unflexibler: ein einfacher GET-Request, mit genau einem Hebel — einen URL-Präfix austauschen (URL_REPLACE). OCI spricht das Tool nicht. Es will einen schlichten Dateiserver, mit derselben URL-Form wie GitHub Releases.

Die angenehme Überraschung: GitLabs generische Package-Registry ist exakt das, auf demselben Host, den ich ohnehin schon betreibe, dual-stack — und ihre URL-Form .../packages/generic/<name>/<version>/<file> passt so sauber auf containerbases <tool>-prebuild/releases/download/<ver>/<file>, dass ein reiner Präfix-Tausch reicht. Um den exakten Dateinamen herauszufinden, den containerbase wollte (welche Ubuntu-Variante? welche Architektur?), zeigte ich URL_REPLACE testweise auf einen frei erfundenen Host und las die Fehlermeldung:

Die Probe (install-tool php 8.5.8)

# URL_REPLACE_0_TO = probe.invalid/cb/  → der Fehler nennt das Asset
ERROR: getaddrinfo ENOTFOUND probe.invalid
  url: "https://probe.invalid/cb/php-prebuild/releases/download/
        8.5.8/php-8.5.8-jammy-aarch64.tar.xz.sha512"

Das Image läuft auf Ubuntu Noble — containerbase fragt aber nach dem Jammy-Prebuild. Das lieber empirisch feststellen, statt zu raten.

03 — Zweite Komplikation: Ein bewegliches Ziel lässt sich nicht vorab befüllen

Das hier war die Komplikation, die wirklich zählte. Bei Providern pinne ich die Versionen selbst — ich entscheide, dass es aws 6.52.0 ist, ich spiegle aws 6.52.0, die Kopplung liegt vollständig in meiner Hand. Renovate läuft dagegen mit binarySource=install — es installiert php und composer bei Bedarf, in genau der Version, die das jeweilige Repository gerade braucht. Das Versions-Set gehört nicht mir. Es ist, was rund 70 Repos zufällig brauchen. Nur eine Version zu spiegeln reicht dann genau bis zum ersten Repo, das eine andere verlangt — dort steht ein 404 mitten im Scan.

Lehre eins

„Einfach spiegeln“ setzt voraus, dass man weiß, was „es“ eigentlich ist. Entscheiden Consumer über das Versions-Set und nicht man selbst, ist Vorab-Befüllung kein Mirror mehr — sondern eine Wette.

Bevor ich also weiteren Code schrieb, kam der unglamouröse Teil: die composer.json jedes verwalteten Repos lesen und zusammentragen, was die php-Installation tatsächlich steuert — zuerst config.platform.php, dann die require.php-Bandbreite.

73 composer.json-Dateien über development, devops und ai-ready-platform hinweg. Jede offene Bandbreite löst auf dieselbe neueste Version auf — nur exakte platform.php-Pins entkommen dem.

Die Panik („ich werde Dutzende Versionen spiegeln und jeder Constraint-Änderung hinterherjagen müssen“) löste sich damit in Luft auf. Das tatsächliche Set war winzig: php 8.5.8 (jede Bandbreite landet hier), php 8.5.0 (fünf Repos pinnen exakt darauf), und composer 2.10.2 (niemand pinnt composer). Drei Artefakte. Das bewegliche Ziel bewegt sich kaum — nur wusste ich das erst, nachdem ich gezählt hatte, statt eine Vermutung zu spiegeln und auf den 404 zu warten.

Der Rest ist damit reine Verrohrung: Ein Job zieht diese drei einmalig von GitHub und pusht sie in die generische Package-Registry; Renovates URL_REPLACE zeigt darauf (Job-Token als Basic-Auth in der URL, weil containerbase keinen Header setzen kann); und weil Renovate die Versionen pro Repo während des Scans installiert, nicht nur einmal vorab, bleibt die Umleitung für den gesamten Job aktiv. Der erste echte geplante Scan nach dem Rollout installierte php und composer direkt aus dem Mirror, über IPv6, ohne 404. Es funktioniert.

04 — Der halbe Sieg: Eine Abhängigkeit zu töten ist nicht dasselbe wie den Pool zu wechseln

Damit zu dem, was ich eigentlich wollte — und nicht bekam. Meine allgemeine CI-Flotte ist IPv6-only, ein kleiner IPv4-Pool existiert für die Jobs, die noch GitHub brauchen. Renovate läuft auf diesem IPv4-Pool. Der eigentliche Sinn der ganzen Übung war in meinem Kopf, es von dort herunterzuholen.

Es steht immer noch dort. Weil ein Renovate-Scan aus zwei völlig unabhängigen Gründen GitHub berührt — und ich nur einen davon behoben habe:

Aus der Distanz sehen der Download-Pfad und der Metadaten-Pfad gleich aus — beide sagen „Renovate braucht GitHub“ — aber es sind nicht dieselbe Art von Problem. Das eine ist eine Datei, die man einmal kopiert und für immer ausliefert. Das andere ist eine Frage, die man GitHub jedes Mal neu stellen muss, und eine Frage zu spiegeln bedeutet, einen Proxy zu betreiben, der sie beantwortet — was wiederum bedeutet, GitHubs API-Oberfläche nachzubauen. Das steht diese Woche nicht an.

Lehre zwei

Einen von mehreren Gründen zu entfernen, warum ein Job das Netzwerk braucht, ist nicht dasselbe, wie den Job vom Netzwerk unabhängig zu machen. Erst die Gründe zählen, bevor man den Pool-Wechsel verspricht.

Also: ehrlich gesagt ein halber Sieg. Die instabile, scan-rot-färbende Abhängigkeit — der Download — ist weg, in Produktion verifiziert. Genau die war es auch wert, gekillt zu werden; sie war es, die aus fremden Ausfällen meine roten Pipelines machte. Renovate bleibt vorerst auf dem IPv4-Pool, und das Dokument, das mitschreibt, was noch IPv4 braucht, behält seine Renovate-Zeile — eine Zeile durchgestrichen, eine steht noch.

Ich nehme das so mit. Ein halber Sieg, der das tatsächliche Problem löst, schlägt einen ganzen Sieg, den man sich nur ausgedacht hat, um sich vollständig zu fühlen.

Fazit

Zwei Geschichten mit derselben Ausgangsdiagnose, zwei sehr unterschiedliche Enden. Bei den Providern kontrolliere ich das Versions-Set, also war Spiegeln ein reines Rohrleitungsproblem. Bei Renovates Toolchain bestimmen 73 fremde Repos das Versions-Set, und containerbase spricht ohnehin kein OCI — beides zusammen macht aus derselben Idee eine andere Aufgabe. Der ehrliche Ertrag: eine instabile, scan-rot-färbende GitHub-Abhängigkeit ist weg, verifiziert in Produktion. Eine zweite bleibt bestehen, weil ihre Behebung eine eigene, deutlich größere Investition wäre. Beide Feststellungen zusammen sind wertvoller als eine geschönte Erfolgsgeschichte.