Jest: Cache Write Race Bedingung über Prozesse hinweg

Ist das nicht verwandt? https://github.com/facebook/jest/pull/4432

Ich glaube nicht. Ich glaube, der Fall, den wir in unserem Repo sehen, ist genau die gleiche Datei, die für zwei verschiedene Prozesse verspottet wird (während sie parallel ausgeführt werden), was dazu führt, dass der Cache-Schreibvorgang fehlschlägt, weil bei einem Prozess die Datei gesperrt ist. Bei diesem Ticket geht es eher um verschiedene Dateien mit demselben Inhalt. Wir haben keinen dieser Fälle in den von uns gehosteten Repositorys, auf die wir bei diesem Problem gestoßen sind.

Grundsätzlich stoßen wir bei unseren Tests auf dasselbe Problem. Eine einfache Möglichkeit zur Reproduktion bestand darin, den Scherz cacheDirectory zu entfernen, um die Cache-Generierung beim nächsten Lauf zu erzwingen.
`` `Testsuite konnte nicht ausgeführt werden

jest: failed to cache transform results in:

C: / myniceproject / src / jest-cache / jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b / 3f / settingsProvider_3f1439e55275c
Fehlermeldung: EPERM: Vorgang nicht zulässig, umbenennen
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e552757957
->
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e552757f

Ich habe das gleiche Problem und kann es nicht umgehen. Scherz ist für uns so grundsätzlich unbrauchbar.

Wir versuchen, von 20.0.4 auf 21.2.0 zu aktualisieren, und jetzt haben wir den folgenden Fehler auf unseren Build-Servern:

Test suite failed to run
[13:46:50]
[13:46:50]    jest: failed to cache transform results in: C:/TeamCity/buildAgent/temp/buildTmp/jest/jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745/3b/fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770
[13:46:50]    Failure message: EPERM: operation not permitted, rename '...\jest\jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745\3b\fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770.1701848979' -> '...\jest\jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745\3b\fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770'
[13:46:50]      
[13:46:50]      at Object.fs.renameSync (fs.js:772:18)
[13:46:50]      at Function.writeFileSync [as sync] (node_modules/write-file-atomic/index.js:192:8)

Ich habe jetzt das gleiche Problem Tests werden zufällig unterbrochen.

Wenn ich die Tests mit dem Flag --runInBand ausführe, ist erwartungsgemäß alles in Ordnung.

Ich kann das gleiche Problem ziemlich konsequent sehen:

  ● Test suite failed to run

    jest: failed to cache transform results in: .../jest-transform-cache-...
    Failure message: EPERM: operation not permitted, rename '...' -> '...'
        at Error (native)

      at Object.fs.renameSync (fs.js:810:18)
      at Function.writeFileSync [as sync] (node_modules/write-file-atomic/index.js:192:8)

Scherz 21.2.1
Knoten 6.11.1
Betriebssystem Windows

--no-cache hilft nicht und jest-transform-cache wird noch geschrieben. Das einzige, was hilft, ist --runInBand , was für große Projekte kaum akzeptabel ist.

Können wir etwas tun, um das Problem zu diagnostizieren? Soll ich einen Repro-Fall erstellen?

Ist dieser Fehler kritisch? Kann es als Warnung behandelt werden, anstatt die gesamte Testsuite herunterzufahren? Gibt es eine Möglichkeit, sich zurückzuziehen und es erneut zu versuchen?

Einen kleinen Repro zu haben wäre großartig

Hier ist der Repro: https://github.com/asapach/jest-cache-issue/
Es führt effektiv lodash-es durch babel-jest , um den Transformationscache zu füllen.
Dies schlägt für mich 80% der Zeit auf zwei verschiedenen Computern (Win8.1 und Win10) fehl.
Wenn Sie --no-cache entfernen, schlägt dies in 100% der Fälle fehl. Durch Hinzufügen von --runInBand der

(Aus Neugier wurde versucht, es in WSL unter Win10 auszuführen, und das Problem ist mit der Posix-API nicht reproduzierbar.)

Passiert das nur unter Windows? Ich habe keinen Zugriff auf Windows-Maschinen außerhalb der virtuellen Maschinen, daher ist es für mich nicht am einfachsten, Fehler zu beheben ...

@jeanlauliac Sie haben write-file-atomic in # 4088 hinzugefügt. Könnten Sie helfen?

Dieses Problem ist https://github.com/npm/write-file-atomic/issues/10 und https://github.com/npm/write-file-atomic/pull/22 sehr ähnlich

Ich habe gerade eine

Tageszeit | Prozessname | PID | Bedienung | Pfad | Ergebnis | Detail
- | - | - | - | - | - | - -
16: 54: 43.2304011 | node.exe | 7624 | SetRenameInformationFile | ... \ Konstante_ee286bbcf367680ce61a90e506522f92.82986661 | ERFOLG | ReplaceIfExists: True, Dateiname: ... \ constant_ee286bbcf367680ce61a90e506522f92
16: 54: 43.2305499 | node.exe | 8208 | SetRenameInformationFile | ... \ Konstante_ee286bbcf367680ce61a90e506522f92.103872574 | ZUGRIFF VERWEIGERT | ReplaceIfExists: True, Dateiname: ... \ constant_ee286bbcf367680ce61a90e506522f92

Wie Sie sehen, versuchen zwei Prozesse, dieselbe Datei innerhalb von 1 ms voneinander umzubenennen, und der zweite schlägt fehl.

Ich denke, npm / write-file-atomic # 22 adressiert die asynchrone Version von writeFile() , aber writeFileSync() ist immer noch betroffen.

Wäre es möglich, einen Repro zu erstellen, der zeigt, dass die Verwendung von write-file-atomic in worker-farm für dieselbe Datei irgendwie fehlschlägt? Es wäre großartig, ein Problem gegen dieses Projekt zu eröffnen, da ich denke, dass hier die Lösung sein sollte.

Oder wenn Sie im Scherz einen Test schreiben könnten, der den gleichen Fehler zeigt (wir haben Appveyor CI), der auch ein Anfang sein könnte?

Ich bin mir nicht mal sicher, welches Verhalten wir im Falle dieses Fehlers wollen. Schreiben wiederholen? Test erneut ausführen? Die ganze Testdatei?

OK, ich werde versuchen, einen weiteren Repro zu erstellen. Ich bin nicht sicher, ob es möglich ist, einen Scherztest zu erstellen, da mehrere Prozesse erzeugt, der Cache deaktiviert / bereinigt und so lange ausgeführt werden müssen, bis er fehlschlägt.

Ich bin mir nicht mal sicher, welches Verhalten wir im Falle dieses Fehlers wollen.

Nun, erstens sollte das Problem nicht einmal auftreten, wenn --no-cache ist, da der Cache nicht gefüllt werden sollte.
Zweitens bin ich mir nicht sicher, ob es möglich ist, den Synchronisierungsvorgang ordnungsgemäß zu wiederholen. Ist es möglich, writeFile() anstelle von writeFileSync() ? Auf diese Weise sollte write-file-atomic automatisch wiederholt werden (ich werde einen Test erstellen, um dies zu bestätigen).

Nun, erstens sollte das Problem nicht einmal auftreten, wenn --no-cache ist, da der Cache nicht gefüllt werden sollte.

Das ist ein guter Punkt und sollte separat behoben werden. Auf diese Weise kann --no-cache zumindest eine Problemumgehung sein.

Zweitens bin ich mir nicht sicher, ob es möglich ist, den Synchronisierungsvorgang ordnungsgemäß zu wiederholen. Ist es möglich, writeFile() anstelle von writeFileSync() ?

@cpojer Gedanken darüber, es nicht synchron zu machen? Ich bin mir nicht sicher, wie das skaliert. Oder wenn Sie eine andere Idee haben, wie Sie dies beheben können

• --no-cache ist eigentlich eher wie --reset-cache . Dies bedeutet, dass der vorhandene Cache nicht verwendet wird, der Cache jedoch weiterhin geschrieben wird. Das möchte ich behalten.
• Diese Vorgänge müssen synchronisiert werden, da sie während require -Aufrufen im Benutzercode ausgeführt werden. Daher können wir dies nicht ändern.

Hier ist der andere Repro mit worker-farm und write-file-atomic : https://github.com/asapach/write-atomic-issue

Bisherige Ergebnisse: Die Synchronisierungsversion schlägt wie erwartet fehl, aber überraschenderweise schlägt auch die Asynchronisierungsversion fehl. Dies bedeutet, dass sie eine Wiederholungswarteschlange wahrscheinlich nur implementieren, wenn sie im selben Prozess ausgeführt wird, was in unserem Fall nicht hilft.

Das möchte ich behalten.

Neue Flagge? Es ist ein sehr irreführender Name. Und auf zB CI möchten Sie den Cache sowieso selten, so dass nur Ressourcen verschwendet werden. Oder wird ein Cache, der in einem einzelnen Testlauf generiert wurde, während --no-cache und nur vorhandene Caches ignoriert?

Hier ist der andere Repro mit worker-farm und write-file-atomic

Genial! Könnten Sie ein Problem gegen Write-File-Atomic eröffnen? Es fühlt sich so an, als ob ein Fix dorthin gehen sollte, und wenn nicht (sie wollen nicht das gleichzeitige Schreiben mehrerer Prozesse unterstützen), können wir auf unserer Seite erneut darüber nachdenken. WDYT?

Ein Patch, den ich lokal ausprobiert habe und der anscheinend funktioniert hat, ignoriert den Fehler, wenn er versucht, in eine Datei mit demselben Inhalt umzubenennen. Da dies nur bedeutet, dass ein anderer Prozess das Rennen „gewonnen“ hat, können wir es ignorieren und weitermachen.

const cacheWriteErrorSafeToIgnore = (
  e: Error,
  cachePath: Path,
  fileData: string,
) => {
  if (
    e.message &&
    e.message.indexOf('EPERM: operation not permitted, rename') > -1
  ) {
    try {
      const currentContent = fs.readFileSync(cachePath, 'utf8');
      return fileData === currentContent;
    } catch (e) {
    }
  }
  return false;
};

@SimenB , sicher, ich werde ein Problem einreichen.

@cpojer , kann dieser Fehler verschluckt / ignoriert und als Warnung behandelt werden? Dies bedeutet, dass die Datei bereits geschrieben wurde und keine Daten verloren gehen sollten.

Upstream-Problem: npm / write-file-atomic # 28

Ich denke, dies bedeutet, dass "Umbenennen" unter Windows keine atomare Operation ist, sodass die Annahme von write-file-atomic . Wenn es kein Flag gibt, das auf Windows-API-Ebene aktiviert werden kann, kann dies bedeuten, dass unter Windows keine atomaren Schreib- / Umbenennungsvorgänge möglich sind.

@jwbay Ihre Lösung sieht für mich vernünftig aus! 👍 Anstatt jedoch indexOf , würde ich e.code === 'EPERM' (robuster, hängt nicht von einer bestimmten Nachricht ab). Ich denke nicht, dass wir die Datei erneut lesen sollten, um den Wert zu überprüfen, da dies zusätzliche Parallelitätsprobleme verursachen könnte (z. B. wenn die Datei gleichzeitig von einem anderen Prozess geschrieben wird). Würde es Ihnen etwas ausmachen, eine PR zu senden?

Ich wollte gerade mit der Arbeit an einer PR für write-file-atomic ähnlich wie "Wenn wir gebeten werden, eine Dateisynchronisierung zu schreiben, diese aber bereits in der Warteschlange steht, um asynchron geschrieben zu werden, retten Sie sich" (möglicherweise mit einer Option) um das Verhalten einzuschalten). Aber wenn wir gerne auf Scherz-Ebene damit umgehen, werde ich mich nicht beeilen. cc @jeanlauliac

Ich wollte gerade mit der Arbeit an einer PR für Write-File-Atomic beginnen, ähnlich wie "Wenn wir gebeten werden, eine Dateisynchronisierung zu schreiben, diese aber bereits in der Warteschlange steht, um asynchron geschrieben zu werden, retten Sie sich" (möglicherweise mit einer Option für Verhalten einschalten).

Ich denke, das Hinzufügen dieser Logik (lokale Warteschlange) würde das Problem nicht beheben, da es meistens passiert, wenn verschiedene Prozesse versuchen, in dieselbe Datei zu schreiben (in dieselbe umzubenennen).

Um Parallelitätsprobleme ein für alle Mal zu beheben, müssen wir möglicherweise überdenken, wie wir das Caching durchführen, z. B. einen einzelnen Prozess, der auf den Cache zugreift und mit dem wir über eine Art IPC kommunizieren. Bestehende Schlüssel- / Wertspeichersysteme können nützlich sein, z. B. memcached .

Ich denke, das Hinzufügen dieser Logik (lokale Warteschlange) würde das Problem nicht beheben, da es meistens passiert, wenn verschiedene Prozesse versuchen, in dieselbe Datei zu schreiben (in dieselbe umzubenennen).

Ah, ich habe das Thema damals vielleicht falsch verstanden. So wie ich es gelesen habe, verfügt die Bibliothek bereits über einen Warteschlangenmechanismus, der für asynchrone Anforderungen gut funktioniert. Wenn Sie jedoch Synchronisierungsanforderungen einmischen, können Kollisionen auftreten.

Meine oben genannte Pull-Anfrage sollte dieses Problem lösen. Zumindest hat es das für mich getan!

@mekwall , ich denke, sie verwenden rename() in der asynchronen Version von writeFile() und es schlägt in meinem Test immer noch fehl: https://github.com/asapach/write-atomic-issue. Könnten Sie bitte versuchen, meinen Repro auszuführen? Ich denke, Ihre Änderung minimiert möglicherweise die Wahrscheinlichkeit, dass dieses Problem auftritt, beseitigt sie jedoch nicht vollständig.

@asapach Hast du es mit meinen Änderungen versucht? Weil ich es mehrmals versucht habe und nie EPERM: operation not permitted, rename mit meinen Änderungen bekommen habe, während ich es jedes Mal ohne bekommen habe.

@mekwall , yep, immer noch fehlgeschlagen mit Ihren Änderungen (obwohl asynchron). (Unten korrigiert.)

Oder technisch gesehen schlägt es nicht fehl (weil der Synchronisierungsfluss nicht unterbrochen wird), aber die Konsole ist immer noch mit EPERM-Fehlern übersät.

@asapach Ich habe das Problem gefunden, das Sie haben. Es befindet sich in der Polyfill graceful-fs . Ich habe einen Fix in dieser PR veröffentlicht: https://github.com/isaacs/node-graceful-fs/pull/119

@mekwall , ja, dies scheint das Problem zu beheben - keine Fehler mehr sowohl in der Synchronisierungs- als auch in der Asynchronisierungsversion.
Das Problem ist jetzt, dass temporäre Dateien nicht entfernt werden, da fs.unlinkSync(tmpfile) niemals aufgerufen wird: https://github.com/npm/write-file-atomic/pull/29/files#diff -168726dbe96b3ce427e7fedce31bb0bcR198

@asapach Ich habe unlink zu graceful-fs umbenennen hinzugefügt, bin mir aber nicht sicher, ob dies der richtige Weg ist. Afaik fs.rename verwendet die MoveFile-Funktion und sollte die Quelle nicht zum Ziel kopieren. Die Quelle sollte nur den Namen ändern und die Quelle und das Ziel sollten niemals gleichzeitig existieren.

@mekwall , das hilft ein bisschen, aber in einigen Fällen, wenn der Worker vorzeitig beendet wird (weil die ganze Arbeit erledigt ist), werden einige Dateien nicht bereinigt, da sie nicht auf die Bereinigung warten. Die asynchrone Version scheint gut zu funktionieren.

@asapach Es funktioniert überhaupt nicht wie erwartet. Ich muss in die Innereien des Knotens eintauchen, um herauszufinden, wie es tatsächlich funktioniert und wie das beabsichtigte Verhalten sein sollte. Ich glaube, der springende Punkt bei Graceful-Fs ist, dass es auf jeder Plattform gleich funktioniert, also werde ich mich eingehender damit befassen. Zumindest haben wir den Täter gefunden :)

@asapach Ich erkannte, dass meine PR für write-file-atomic nicht funktionieren würde, also ging ich anders vor, indem ich fs.renameSync in graceful-fs mit den gleichen Problemumgehungen wie fs.rename hinzufügte aber blockieren. So funktioniert Ihr Test wie erwartet!

@mekwall , danke, ich habe Ihre Änderungen in meinen beiden Repro-Fällen überprüft und keiner von ihnen
Ich denke, auf der anderen Seite sehe ich eine erhöhte CPU- und Festplattenauslastung für die Synchronisierung, aber es wird wahrscheinlich erwartet.

Vielen Dank, dass Sie dies aufgegriffen und dabei geholfen haben, es zu reparieren. Sehr geschätzt! ❤️ Hoffentlich ist das Update in Graceful-Fs das richtige und wird veröffentlicht.

@SimenB Gern geschehen ! Das schmerzt uns bei der Arbeit, deshalb habe ich etwas Zeit, um dies von meinem Team zu untersuchen. Die Änderungen wirken sich auf viele Pakete aus, sodass es höchstwahrscheinlich einige Zeit dauern wird, bis sie diese akzeptieren: /

Gibt es eine Idee, wann diese Problemumgehung zu einer Veröffentlichung führt?

@cpojer könnten Sie weitere Informationen geben, warum es geschlossen ist? Gibt es einen Fix? Wir haben immer noch dieses Problem

Entschuldigung, scheint, dass das Update noch nicht in Graceful-Fs gelandet ist :(

Können mehrere Personen bestätigen, dass die Verwendung von https://github.com/isaacs/node-graceful-fs/pull/119 ihre Probleme behebt?

Sie können die Gabel mithilfe von Garnauflösungen verwenden, siehe https://yarnpkg.com/de/docs/selective-version-resolutions , mit denen Sie den Fix auf CI usw. bereitstellen können.

z.B

{
  "resolutions": {
    "graceful-fs": "mekwall/node-graceful-fs#a10aa576f771d7cf3dfaee523f2e02d6eb11a89f"
  }
}

@SimenB Es löst das Problem für mich, zumindest 😄

+1 Auch für mich.

@SimenB Auch mein Problem wurde behoben und ich kann jetzt Jest 22 unter Windows verwenden. (Wir waren am 20. vorher fest).

Bearbeiten: Eigentlich funktionierte es auf meinem Entwickler-Laptop, aber nicht auf dem Build-Server. Es läuft Garn 1.2.1, vielleicht ist das der Grund?

[16:47:55][Step 5/8]     jest: failed to read cache file: D:/TeamCity/buildAgent2/temp/buildTmp/jest/jest-transform-cache-c39254d365b4bcb2c90f133d4b359d91-56a1804d8d831b3401a35a7e81857f3b/7e/rafPolyfill_7e7a83ed3f2680ba9aec0e45f59ade5d
[16:47:55][Step 5/8]     Failure message: EPERM: operation not permitted, open 'D:\TeamCity\buildAgent2\temp\buildTmp\jest\jest-transform-cache-c39254d365b4bcb2c90f133d4b359d91-56a1804d8d831b3401a35a7e81857f3b\7e\rafPolyfill_7e7a83ed3f2680ba9aec0e45f59ade5d'
[16:47:55][Step 5/8]       
[16:47:55][Step 5/8]       at readCacheFile (node_modules/jest-runtime/build/script_transformer.js:465:60)

Garn 1.0.0 sollte ausreichen, ein Upgrade lohnt sich jedoch

Ich habe gerade versucht, die Auflösung einzufügen, aber es schlägt immer noch für mich fehl. Ich habe jedoch sowohl ENOENT- als auch EPERM-Verstöße:

    jest: failed to read cache file: C:/Users/dev/AppData/Local/Temp/jest/jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679/7d/index_7d0afc82f0b29ec31c4b5f296cbdee74
    Failure message: ENOENT: no such file or directory, open 'C:\Users\dev\AppData\Local\Temp\jest\jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679\7d\index_7d0afc82f0b29ec31c4b5f296cbdee74'

      at Object.fs.openSync (../fs.js:653:18)
      at Object.fs.readFileSync (../fs.js:554:33)

und

    jest: failed to read cache file: C:/Users/dev/AppData/Local/Temp/jest/jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679/c4/std_pb_c403e6e7645c904896b66f44a3e43606
    Failure message: EPERM: operation not permitted, open 'C:\Users\dev\AppData\Local\Temp\jest\jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679\c4\std_pb_c403e6e7645c904896b66f44a3e43606'

      at Object.fs.openSync (../fs.js:653:18)
      at Object.fs.readFileSync (../fs.js:554:33)

@mreishus Läuft auf Ihrem Build-Server Windows? Da die Korrekturen in graceful-fs nur auf Windows abzielen, sollte dies jedoch nicht auf einem Linux-basierten Betriebssystem geschehen.

@mekwall ja, Windows - aber es ist Windows Server 2012 R2

Dies ist ein großes Problem für mich und seit November 2016 ist mit graceful-fs nichts mehr passiert, was ich sehen kann. Daher bin ich ziemlich pessimistisch, dass das bereitgestellte Update @mekwall nicht so schnell zusammengeführt wird. Gibt es eine vorübergehende Lösung, die wir außer dem Flag -i und der Problemumgehung für die Auflösung verwenden können?

Funktioniert --runInBand bei Ihnen nicht @frenic?

Das ist das gleiche wie -i und ja, es funktioniert. Leider ist es bei größeren Projekten auf lange Sicht nicht nachhaltig.

Ich denke, wir könnten unsere eigenen teilen und veröffentlichen, aber es scheint nicht, dass das Update für alle funktioniert

Ich bin mit der gleichen Situation fertig, aber in meinem Fall funktioniert --runInBand nicht.

Ich habe die Überschreibung von graceful-fs mit der neuesten Version von Jest überprüft und leider scheint sie seit meinem letzten Test nicht mehr so ​​zuverlässig zu funktionieren. Es besteht immer noch eine Wahrscheinlichkeit ungleich Null, dass es in großen Testsuiten zu einem Rennzustand kommt.

Nachdem ich durch diesen Thread gescrollt hatte, fand ich eine Auflösung mit yarn . Gibt es eine Lösung, npm stattdessen

Wir hatten bisher ziemlich viel Glück, als wir die gepatchte Version von graceful-fs zu unserem package.json hinzugefügt haben. Funktioniert bei uns mit npm und Garn.

"graceful-fs": "https://github.com/mekwall/node-graceful-fs.git#patch-1",

Hallo,

Aus irgendeinem Grund wird dieser Fehler nur beim Ausführen von Jenkins angezeigt, nicht beim lokalen Ausführen (sogar auf demselben Computer / Ordner usw.).
Die Lösung von @jsheetzati funktioniert auch für uns (mit npm), aber es ist doch ein Patch. Gibt es eine ETA, um dies dauerhaft zu lösen?

Vielen Dank,
Mor

Wir haben dieses Problem auch, wenn wir einen Scherz von Jenkins machen. --runInBand Option
Um dieses Problem zu umgehen, verwenden wir das abschließbare Ressourcen , um sicherzustellen, dass nur ein jest -Prozess gleichzeitig ausgeführt wird, wobei die Option --runInBand beibehalten wird.
Hoffe, dieser Kommentar wird für jemanden nützlich sein.

@nyrkovalex Um das von Ihnen beschriebene Problem zu vermeiden, verwenden wir die Cache-Verzeichnisoption von Jest , um sicherzustellen, dass der Cache nicht für alle Arbeitsbereiche freigegeben wird.

Dazu veröffentlichen wir eine Jest-Voreinstellung, die cacheDirectory: '<rootDir>/.jest-cache' festlegt, und stellen sicher, dass alle Pakete diese verwenden. Wenn Sie dies tun, stellen Sie sicher, dass Sie .jest-cache zu .gitignore hinzufügen.

Bevor wir diese Option hinzufügen, treten verschiedene Probleme auf, da ein globaler Jest-Cache von 16 Executoren pro Jenkins-Agent gemeinsam genutzt wird. Die Verwendung abschließbarer Ressourcen verhindert auch die von Ihnen erwähnten Probleme, ist jedoch verschwenderisch, da Sie Ihren Jenkins-Agenten nicht optimal nutzen (da die Scherz-Tests zu einem Engpass werden).

@ anescobar1991 Diese Option ist definitiv eine bessere Lösung. Wir werden sie in Betracht ziehen.
Danke für einen Tipp!

Hallo,

Wir verwenden Gradle, um npm auszuführen (fragen Sie nicht warum :)) und die Kombination davon mit Jenkins ist ein Killer.
Wir haben es versucht:

1. Festlegen, dass sich der Cache im lokalen Verzeichnis statt im globalen Cache befindet
2. mit --runInBand
3. Auf dem Agenten wird nur ein einziger Job ausgeführt - keine parallelen Jobs
4. Gradle-Test ausführen --max-worker 1 (und nicht --parallel verwenden)

Alle scheitern mit dem gleichen Fehler.
Die einzige Lösung, die für uns funktioniert, ist die von @jsheetzati - ich wünschte, dies würde formal behoben.

Wir könnten wahrscheinlich mit diesem Fix verzweigen und veröffentlichen

das wäre super...

Ich habe dieses Problem sehr oft und der Patch für anmutige fs hat bei mir funktioniert. Ich würde mich also über dieses Update freuen.

Könnten Sie nicht einfach jedem Worker-Prozess / Thread ein eigenes Cache-Verzeichnis zuweisen, um die Race-Bedingung zu vermeiden, um das Problem mit Graceful-Fs zu lösen?

Es ist wahrscheinlich langsam, aber wir müssen --runInBand auf unserem CI-Server verwenden, und das ist viel schlimmer.

Wenn mich jemand auf die richtigen Dateien hinweisen kann, könnte ich sogar versuchen, einen Patch zu schreiben. Es fällt mir wirklich schwer, durch die Quelle des Scherzes zu navigieren.

Ich bin mir nicht sicher, was es ist, aber es sind einige Wochen, möglicherweise einige Monate vergangen, und ich habe den Fehler nicht mehr beobachtet. Wir verwenden Jest 22.4.2 seit einiger Zeit und haben kürzlich ein Upgrade auf 22.4.4 durchgeführt. Wir haben auch verschiedene andere Pakete aktualisiert.

Nur um einzusteigen - ich sehe dies mit Scherz 23.6 auf einem Windows Jenkins CI-Server.

• --runInBand funktioniert, verdoppelt aber die Testzeit, daher ist es nicht großartig. Da wir Tests vor dem Push ausführen, kann ich dies nicht aktivieren, ohne meine Teammitglieder überaus traurig zu machen
• Das von @jsheetzati (https://github.com/facebook/jest/issues/4444#issuecomment-370533355) erwähnte package.json funktioniert, ist aber ein bisschen hackig .

Da graceful-fs nicht viel dagegen unternimmt (https://github.com/isaacs/node-graceful-fs/pull/131 hat seit Juli letzten Jahres keine Aktion mehr gesehen), ist es vielleicht Zeit zu gabeln ? Ich habe dort einen nörgelnden Kommentar hinzugefügt, aber ich erwarte nicht, dass irgendjemand plötzlich dazu kommt, dies zu klären.

Ich habe das gleiche Problem, aber die Fehlermeldung ist unterschiedlich
Failure message: EBADF: bad file descriptor, close

jest: failed to cache transform results in: C:/agent/_work/_temp/jest/jest-transform-cache-2a12bf9796741cb06fb97a276aa09712-7d718cda2d798ae78eb741b3feff799e/7b/test-setup_7bdb1937d8dbbf5088142bc21e74a530
2019-01-24T13:44:55.5496091Z     Failure message: EBADF: bad file descriptor, close

Es scheint, dass das Ausführen von Jest mit --runInBand das Problem nicht beim ersten Mal löst, sondern erst nach einem weiteren Ausführen fehlerfrei ausgeführt wird.

Wird unter Windows 10 Enterprise VM als Teil eines TFS-Builds ausgeführt.

@EthanSankin kannst du auch mit der verknüpften

Ich arbeite an einem Ersatz für graceful-fs , der diese Probleme lösen soll. Es ist derzeit in Alpha, aber es wäre großartig, einige Early Adopters zu bekommen: https://github.com/mekwall/normalized-fs

Das Zurücksetzen auf eine ältere Version von Write-File-Atomic löste das Problem.

@moizgh von welcher Version zu welcher Version?

@moizgh von welcher Version zu welcher Version?

2.4.2 bis 2.3.0

@iarna scheint, als wäre eine Regression eingeführt worden.

Gibt es auch Einblicke in eine bessere / dauerhafte Lösung?

Dies begann für uns in den letzten Monaten wieder - Fenster - sehr sporadisch.

write-file-atomic verwendet keine Graceful-Fs mehr - vielleicht hat das etwas damit zu tun?