Einen 403-fehlgeschlagenen GitHub-Actions-Auto-Commit debuggen

CI/CD-Pipeline-Optimierung: Build-Zeiten um 70 % reduzieren

Praktische Strategien zur Optimierung von CI/CD-Pipelines, einschließlich Caching-Strategien, paralleler Ausführung und Ressourcenmanagement, um die Build-Zeiten drastisch zu reduzieren.

Der Workflow war fast perfekt: Er validierte, transformierte, optimierte und – der Teil, den jeder für Magie hält – pushte das optimierte Ergebnis zurück auf main. Der letzte Schritt am Ende starb mit zwei kryptischen Zeilen:

remote: Permission to owner/repo.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/...': The requested URL returned error: 403
Error: Invalid status code: 128

Die Optimierung hatte ihre Arbeit tatsächlich getan – die check:palette- und Asset-Schritte liefen sauber. Was fehlschlug, war der finale Auto-Commit-Push. Die Ursache ist langweilig, vorhersehbar und in zwei Zeilen behebbar.

Das standardmäßige GITHUB_TOKEN ist read-only

GitHub injiziert jedem Workflow-Lauf ein GITHUB_TOKEN. Für neuere Repositories ist die Standardberechtigung dieses Tokens für Contents read – genug, um das Repo auszuchecken, nicht genug, um zurückzupushen. Jeder Schritt, der committet und pusht, scheitert also im Moment der Wahrheit mit 403 / Exit 128.

Das verräterische Zeichen, dass du hier anstößt und nicht an einer falschen Auth-Konfiguration: Der 403 nennt github-actions[bot] ausdrücklich. Es ist nicht so, dass dein Login falsch ist – das Token hat einfach keinen Schreibraum.

Der Fix: ein Zwei-Zeilen-Permissions-Block

Ganz oben im Workflow, vor jedem Job, deklariere die Berechtigung, die du wirklich brauchst:

permissions:
  contents: write

Dieser einzelne Block gewährt dem GITHUB_TOKEN des Workflows Schreibzugriff auf Repo-Inhalte – genau das, was ein Auto-Commit braucht. (Wende das Prinzip der geringsten Rechte an: Gib contents: write nur, wenn ein Job wirklich committet und pusht; Workflows, die nur lesen, sollten es nicht tragen.)

Das Ergebnis ist sofort und langweilig: Der Auto-Commit pusht, die Pipeline ist fertig, und die generierten Änderungen landen als echter Commit auf main.

Die irreführenden Flags (Least-Surprise-Leitplanken)

Während der Diagnose zeigten die Logs außerdem zwei nicht-fatale Warnungen, die in die falsche Richtung wiesen, wenn man ihre Bedeutung nicht kennt:

Unexpected inputs 'commit_if_no_changes', 'skip_check_run'
lint-staged could not find any staged files matching configured tasks.

• commit_if_no_changes und skip_check_run sind Inputs, die deine Aktionsversion nicht deklariert – harmlose „unexpected input"-Warnungen, nicht die Ursache.
• Die lint-staged-Meldung ist der Pre-Commit-Hook der Action, der keine gestagten Dateien findet, die zu seinen Tasks passen. Sie ist eine Warnung; die Action fährt fort. Sie kann dich eine lint-staged-Konfig jagen lassen, die nicht das Problem ist.

Keine von beiden verursacht den 403. Sei misstrauisch gegenüber beiden, aber behebe sie nicht zuerst.

Die Reihenfolge, die es wirklich beweist

Die saubere Diagnosereihenfolge:

1. Lies das Log des letzten Schritts und bestätige, dass der Fehler beim Push auftritt und github-actions[bot] nennt – das pinnt ihn auf den Token-Scope.
2. Bestätige, dass die vorherigen Transform-/Validate-Schritte bestanden haben (bei uns taten sie das) – das schließt ein Daten- oder Inhaltsproblem aus.
3. Füge permissions: contents: write auf Workflow-Root-Ebene hinzu.
4. Starte neu. Der Auto-Commit pusht jetzt erfolgreich, und der daraus entstandene automatisch generierte Commit auf main ist dein Beweis.

Eine selbsttragende Artefakt-Pipeline – Assets optimieren, Ergebnis pushen, CI neu validieren lassen – ist mächtig. Aber sie hängt stillschweigend davon ab, dass das Token Schreibzugriff hat, und der Default gewährt ihn nicht mehr. Zwei Zeilen YAML verwandeln einen scheiternden Auto-Commit zurück in die langweilige Hintergrundmechanik, die er immer sein sollte.