Lokal grün, im CI rot: Meist unterscheidet der Linux-Server Groß- und Kleinschreibung bei Dateinamen – Windows und macOS tun das nicht.
Aufwand:
ca. 30 Min.
Das Symptom
Der Build läuft lokal einwandfrei durch. Dieselbe Version im CI scheitert mit einem
Modul, das nicht gefunden werden kann – obwohl die Datei nachweislich im Repository
liegt und der Pfad korrekt aussieht.
Die „Layer 8“-Wahrheit
„Bei mir läuft es“ ist der Satz, mit dem dieses Problem beginnt, und er ist sogar
wahr. Er beschreibt nur eine andere Welt.
Windows und macOS speichern die Schreibweise von Dateinamen zwar, unterscheiden
beim Suchen aber nicht zwischen Groß- und Kleinschreibung. Button.tsx und
button.tsx sind dort dieselbe Datei. Linux – und damit praktisch jeder Build-Server
dieser Welt – sieht das anders: Das sind zwei verschiedene Dateien, Punkt. Ein
Import, der lokal aus purer Nachsicht des Dateisystems funktioniert hat, fliegt im
CI auf.
Besonders hinterhältig ist die Reparatur. Wer die Datei lokal umbenennt, indem er
einen Buchstaben groß schreibt, bekommt von Git ein Schulterzucken: Das Dateisystem
meldet, dass sich nichts geändert hat, also sieht Git keine Änderung, also landet
nichts im Commit. Man hat den Fehler behoben, gepusht – und der CI scheitert
unverändert weiter. Genau deshalb braucht es die explizite Umbenennung. Sonst
diskutiert man mit einer Pipeline, die etwas ganz anderes sieht als der eigene
Editor.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Den Import mit der Datei vergleichen
Die Fehlermeldung nennt den Pfad, der nicht gefunden wurde. Diesen Pfad Zeichen für Zeichen mit dem tatsächlichen Dateinamen vergleichen – inklusive Groß- und Kleinschreibung. Genau dort liegt der Unterschied.
2.
Die Ursache verstehen
Windows und macOS behandeln Dateinamen standardmäßig ohne Rücksicht auf Groß- und Kleinschreibung. Linux tut das nicht. Ein Import von Button funktioniert lokal auch dann, wenn die Datei button heißt – auf dem Linux-Server der Pipeline nicht.
3.
Die Datei korrekt in Git umbenennen
Eine reine Änderung der Groß- und Kleinschreibung bemerkt Git auf einem Dateisystem ohne diese Unterscheidung nicht. Deshalb wird explizit umbenannt, sonst landet die Korrektur nie im Repository.
Auf weitere Unterschiede zwischen lokal und CI achten
Nicht jeder CI-Fehler ist ein Namensproblem. Häufig sind auch eine andere Node-Version, fehlende Umgebungsvariablen oder Abhängigkeiten, die lokal noch im Cache liegen, im CI aber frisch installiert werden.
5.
Reproduzierbar installieren
Im CI wird nicht wie lokal installiert, sondern streng nach der Sperrdatei. Wer lokal dasselbe tut, findet Abweichungen, bevor die Pipeline sie findet.
npm ci
Häufige Fragen (FAQ)
?Warum merkt Git die Umbenennung nicht?
Weil Git das Dateisystem fragt, und ein Dateisystem ohne Unterscheidung von Groß- und Kleinschreibung meldet, dass sich nichts geändert hat. Deshalb braucht es die explizite Umbenennung – sonst bleibt im Repository der alte Name stehen und der CI scheitert weiter.
?Kann ich mein lokales Dateisystem einfach umstellen?
Möglich ist es, aber es bricht regelmäßig Werkzeuge, die damit nicht rechnen. Die zuverlässigere Disziplin ist eine Prüfung in der Pipeline und eine klare Namenskonvention – nicht das Umstellen des eigenen Rechners.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
npm install -g bricht mit 'EACCES: permission denied' ab? Nicht sudo verwenden. So installierst du globale Pakete korrekt über nvm oder ein eigenes Prefix.