Closed dh3wr closed 6 years ago
Vor dem eigentlichen Build-Vorgang löscht webpack bereits das gesamte dist/
-Verzeichnis.
Allerdings vermute ich, dass währenddessen das Update der Coveragefiles durchgeführt wurde, sodass das Verzeichnis erneut erstellt wurde. Also einfach nochmal versuchen oder temporär den Update-Cron deaktivieren...
Definitiv kein Cronjob zur Build-Zeit aktiv, ich denke eher, dass ''rmdir'' ein leeres Dir erwartet. Vielleicht besser ''rm -r ...''
Die Library dahinter führt bereits ein rm -rf
durch und bisher kann ich das Problem auch nicht nachvollziehen.
Schneller Fix: dist/
-Verzeichnis vorher von Hand löschen und danach npm run build
starten.
Kommt immer wieder. Vielleicht ist das rm -rf nicht an der richtigen Stelle? Das Verzeichnis ist auch definitiv noch da und gefüllt.
Seit wann genau tritt der Fehler auf? Wo und wann rufst du das npm run build
auf?
An dem Skript wurde seit Ewigkeiten nichts geändert und nachstellen kann ich das leider auch nicht...
Geh einfach per ssh mit rwth-afu
auf dapnet.db0sda.ampr.org in /opt/Web
und mach npm run build
. Dann siehst du das Problem.
Das Problem ist der Sender db0luh gewesen, der ein \u200b
(https://www.fileformat.info/info/unicode/char/200B/index.htm) am Ende seines Namens stehen hatte. Das Zeichen hat dafür gesorgt, dass der Dateiname der Coveragefiles nicht mehr richtig gelesen werden konnte. Deshalb hat das Buildskript das Verzeichnis auch nicht problemlos löschen können.
Ich habe den Sendernamen im DAPNET Web neu eingetragen, die Coveragefiles auf compass2 und web.db0sda.ampr.org gelöscht und der Buildvorgang scheint wieder zu laufen. Das müssen wir aber mal beobachten und schauen, dass solche Zeichen nicht mehr in Sendernamen hinein geraten. Bin mir nicht sicher, ob #154 diesen Fall auch abdeckt...
Wohl nicht
request.url = request.url.replace(/ /g, '');
Replace doch auch \u200b
Oder direkt alle Zeichen außer a-zA-Z0-9-_
Mit https://github.com/DecentralizedAmateurPagingNetwork/Web/commit/201b655e3618003f5868f23f2957c11c3d64f618 werden jetzt alle zero-width unicode Zeichen gefiltert.
Außerdem scheint das Problem mit der Umbenennung von db0luh nicht mehr aufzutreten.
Stand: 19906fbf25a66133d0310fea436dece40df90074 Im Grunde könnte das Verzeichnis doch voll bleiben oder wenn nicht, dann in dem Build-Process den Inhalt löschen.