PHP mit GitLab CI auf einem Remote-Mac scheitert oft an langsamen grenzüberschreitenden Downloads, 401 auf privaten VCS-URLs oder Lock-Drift zwischen Spiegel und Packagist. Hier finden Sie eine kompakte Matrix: Repository-Reihenfolge, composer config-Zeilen, Proxy/Retry, COMPOSER_CACHE_DIR und Cache-Keys — ohne Login: Startseite, Blog, Hilfe. Mehr CI-Pull-Themen: Gradle/Maven, Git/npm/Homebrew, Deno/JSR.

Szenario und Engpässe: grenzüberschreitende Pull-Timeouts, Authentifizierung und Lock-Konsistenz

Typischerweise dominieren drei Engpass-Typen: Netz (Latenz/DPI zu Packagist), Auth (private GitLab-URLs ohne Token) und Lock-Drift (Lock gegen anderen Spiegel/PHP-Minor erzeugt). Symptome: Timeouts, 401 oder überraschende Versionsunterschiede.

  • Timeouts: Zu viele parallele TLS-Sessions über eine schwache Route — zuerst Parallelität drosseln, dann Spiegel näher am Runner.
  • Auth: Ohne gitlab-token.<host> oder Deploy-Key bricht HTTPS-VCS in der CI sofort ab.
  • Lock: Gleiche repositories-Reihenfolge in Dev und CI; Lock nur nach dokumentiertem composer update committen.
Symptom Schnell-Fix
Langsamer Install trotz idle-CPU COMPOSER_MAX_PARALLEL_HTTP senken; regionalen Spiegel priorisieren
401 auf VCS gitlab-token / PAT prüfen; Host exakt wie in composer.json

Packagist, regionale Spiegel und Firmen-Repositories: Ketten-Fallback mit ausführbaren composer config-Zeilen

Composer durchläuft repositories in Reihenfolge: Firmen-Repo (Nexus/Artifactory/GitLab Registry), optional regionaler OSS-Spiegel (nur nach Freigabe), dann repo.packagist.org. URLs an Ihre Policy anpassen; Zeilen unten direkt ausführbar (--global bei Bedarf weglassen).

composer config --global repos.internal composer https://nexus.example.com/repository/composer-hosted/ composer config --global repos.cn-mirror composer https://mirrors.example.cn/composer/ composer config --global repos.packagist composer https://repo.packagist.org composer config --global secure-http true composer config --global gitlab-domains gitlab.example.com gitlab.com composer config --global gitlab-token.gitlab.example.com "${CI_JOB_TOKEN}"

Tokens nur als CI-Variablen; nie PATs in composer.json. Kette: 1) Firmenspiegel mit Upstream 2) CN/EU-Spiegel 3) Packagist — Sync-Verzögerung am Spiegel im Runbook vermerken. Die Reihenfolge sollte für alle Builds identisch und auditierbar sein.

Parallelität mit GitLab CI: HTTP-Proxy, gleichzeitige Jobs und Retry-Backoff-Checkliste

Mehrere Jobs auf einem Mac teilen sich Bandbreite und IOPS — erhöhen Sie nicht gleichzeitig Pipeline-parallel: und COMPOSER_MAX_PARALLEL_HTTP. Messen Sie die Install-Phase mit einfacher Zeitstempel-Logzeile, bevor Sie weitere Runner-Prozesse hinzufügen. HTTP(S)_PROXY mit NO_PROXY für interne Registry, GitLab-Host und 127.0.0.1 setzen, sonst Proxy-Schleifen und doppelte Authentifizierung.

  • COMPOSER_MAX_PARALLEL_HTTP 4–6 (geteilter Runner); max. 8 nur bei stabiler Leitung.
  • retry: in GitLab z. B. max: 2 mit Pause 2s / 4s / 8s — nicht bei 401 wiederholen.
  • Schrittfolge: composer validate --no-check-publish, dann composer install --no-interaction --prefer-dist, Release mit --no-dev.

Cache auf dem Remote-Mac: COMPOSER_CACHE_DIR, Verzeichnislayout und typische CI-Cache-Keys

Auf geteilten Remote-Macs: COMPOSER_CACHE_DIR auf NVMe legen (nicht Netzwerk-Home), z. B. /usr/local/ci/composer/cache, Schreibrechte für den Runner-Benutzer. Optional COMPOSER_HOME ebenfalls auf SSD halten, damit globale Config nicht auf langsames Volume zeigt. GitLab cache: auf denselben Tree zeigen.

export COMPOSER_CACHE_DIR="/usr/local/ci/composer/cache" mkdir -p "$COMPOSER_CACHE_DIR"

CI-Cache-Key: Hash von composer.lock plus PHP-Minor (php -r 'echo PHP_VERSION;'); optional Kurz-Suffix bei Spiegel-Wechsel. Ein Ordner pro Pool maximiert Trefferquote; strikte Trennung nur bei Compliance-Vorgaben.

Rollout in fünf Schritten (Remote-Mac-Agent)

  • 1. PHP-Minor + Composer 2.x in before_script loggen.
  • 2. composer config / auth.json ohne Klartext-Secrets.
  • 3. Proxy + NO_PROXY mit curl -I testen.
  • 4. COMPOSER_CACHE_DIR + GitLab-cache: setzen.
  • 5. composer install, dann Tests; Flakes mit Backoff retry.

Kurzreferenz für Runbooks

4–6 parallele HTTP-Downloads sind auf geteilten Apple-Silicon-Runnern ein guter Start. Cache-Key = Lock + PHP-Minor. CI_JOB_TOKEN wirkt nur bei passendem gitlab-token.<host>; Fork-PRs beachten.

FAQ: HTTP 401, Rate-Limits und fehlgeschlagene Hash-Prüfungen

Warum composer install mit 401 auf einer GitLab-VCS-URL?

Mit -vvv die URL prüfen; gitlab-token-Host muss exakt passen; Scopes und Projekt-Sichtbarkeit für den Job. SSH: Deploy-Key statt HTTPS-Token.

429 oder „rate limit“ vom Spiegel oder Packagist?

Parallelität runter, Builds versetzen, näheren Spiegel nutzen; Backoff 2/4/8s, max. drei Versuche — bei 401 Auth fixen, nicht retry.

Hash- / Checksum-Fehler nach Download?

composer clear-cache, SSL-Inspecting-Proxy und Firmen-CA prüfen, Spiegel-Sync verifizieren; erneut installieren und Paketnamen loggen.

Fazit

Fazit (2026): Repository-Kette, GitLab-Tokens, gedrosselte Parallelität, Proxy/NO_PROXY, Backoff-Retries und NVMe-COMPOSER_CACHE_DIR mit Lock/PHP-Cache-Key bilden das Gerüst. Ein gemieteter Apple-Silicon-Mac hält die Pipeline erreichbar statt Heim-PC. Ohne Login: Startseite, Kaufen, Preise, Hilfe, Blog.

Composer × GitLab × Remote-Mac

Remote-Mac für PHP-Pipelines mieten

Hilfe zu SSH und Erstzugriff, Kaufen für Pakete, Preise vergleichen und im Technik-Blog weitere CI-Matrizen lesen.

Preise ansehen Jetzt kaufen Weitere Artikel
Apple-Silicon
Dedizierter Build-Host
GitLab Runner tauglich