Jest: kondisi balapan tulis cache di seluruh proses

Bukankah ini terkait? https://github.com/facebook/jest/pull/4432

Saya tidak percaya begitu. Saya percaya kasus yang kami lihat di repo kami adalah file yang sama persis yang diejek untuk 2 proses berbeda (saat berjalan secara paralel) yang menyebabkan operasi penulisan cache gagal karena satu proses memiliki file yang terkunci. Tiket itu sepertinya lebih banyak tentang file berbeda dengan konten yang sama. Kami tidak memiliki kasus-kasus tersebut di repositori yang kami hosting yang mengalami masalah ini.

Kami pada dasarnya mengalami masalah yang sama dengan pengujian kami. Salah satu cara mudah untuk mereproduksi adalah dengan menghapus lelucon cacheDirectory untuk memaksa pembuatan cache pada proses berikutnya.
`` Test suite gagal dijalankan

jest: failed to cache transform results in:

C: / myniceproject / src / jest-cache / jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b / 3f / settingsProvider_3f1439e55275a795ecfdb7dc
Pesan kegagalan: EPERM: operasi tidak diizinkan, ganti nama
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a795ecfdb7d29c137
->
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a795ecfdb7dc

Memiliki masalah yang sama dan tidak dapat menemukan jalan keluarnya. Jest pada dasarnya tidak dapat digunakan bagi kami seperti ini.

Kami mencoba memperbarui ke 21.2.0 dari 20.0.4 dan sekarang kami mengalami kesalahan berikut pada server build kami:

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)

Saya sekarang mengalami tes masalah yang sama rusak secara acak.

Jika saya menjalankan tes dengan flag --runInBand maka seperti yang diharapkan semuanya OK.

Saya dapat melihat masalah yang sama secara konsisten:

  ● 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)

lelucon 21.2.1
simpul 6.11.1
OS Windows

--no-cache tidak membantu dan jest-transform-cache masih ditulis. Satu-satunya hal yang membantu adalah --runInBand , yang hampir tidak dapat diterima untuk proyek besar.

Adakah yang dapat kami lakukan untuk membantu mendiagnosis masalah? Haruskah saya membuat kasus repro?

Apakah kesalahan ini kritis? Bisakah itu diperlakukan sebagai peringatan daripada menghapus seluruh rangkaian pengujian? Apakah ada cara untuk mundur dan mencoba lagi?

Memiliki repro kecil akan bagus

Ini repro: https://github.com/asapach/jest-cache-issue/
Ini secara efektif menjalankan lodash-es melalui babel-jest untuk mengisi cache transformasi.
Bagi saya ini gagal 80% dari waktu pada dua mesin yang berbeda (Win8.1 dan Win10).
Jika Anda menghapus --no-cache itu gagal 100% dari waktu. Menambahkan --runInBand akan menurunkannya menjadi 0%.

(Karena penasaran mencoba menjalankannya di WSL di Win10 dan masalah tidak dapat direkonstruksi menggunakan API Posix)

Apakah ini baru saja terjadi di Windows? Saya tidak memiliki akses ke mesin windows selain mesin virtual, jadi bukan yang termudah untuk men-debug untuk saya ...

@jeanlauliac Anda menambahkan write-file-atomic di # 4088, apakah Anda dapat membantu?

Masalah ini sangat mirip dengan https://github.com/npm/write-file-atomic/issues/10 dan https://github.com/npm/write-file-atomic/pull/22.

Baru saja menjalankan jejak procmon , berikut adalah contoh masalahnya:

Waktu Hari | Nama Proses | PID | Operasi | Jalan | Hasil | Detail
- | - | - | - | - | - | -
16: 54: 43.2304011 | node.exe | 7624 | SetRenameInformationFile | ... \ constant_ee286bbcf367680ce61a90e506522f92.82986661 | SUKSES | ReplaceIfExists: True, FileName: ... \ constant_ee286bbcf367680ce61a90e506522f92
16: 54: 43.2305499 | node.exe | 8208 | SetRenameInformationFile | ... \ constant_ee286bbcf367680ce61a90e506522f92.103872574 | AKSES DITOLAK | ReplaceIfExists: True, FileName: ... \ constant_ee286bbcf367680ce61a90e506522f92

Seperti yang Anda lihat, dua proses mencoba mengganti nama file yang sama dalam jarak 1ms satu sama lain dan yang kedua gagal.

Saya pikir npm / write-file-atomic # 22 mengalamatkan versi asinkron dari writeFile() , tetapi writeFileSync() masih terpengaruh.

Mungkinkah membuat repro yang menunjukkan bahwa hanya menggunakan write-file-atomic dalam worker-farm terhadap file yang sama gagal entah bagaimana? Akan sangat bagus untuk membuka masalah terhadap proyek itu, karena saya pikir di situlah seharusnya perbaikan.

Atau jika Anda bisa menulis tes dalam lelucon yang menunjukkan kesalahan yang sama (kami memiliki CI appveyor) yang bisa menjadi permulaan juga?

Saya bahkan tidak yakin perilaku apa yang kami inginkan jika terjadi kesalahan ini. Coba tulis lagi? Jalankan kembali tesnya? Seluruh file tes?

Oke, saya akan mencoba membuat repro lain. Tidak yakin itu mungkin untuk membuat tes lelucon, karena itu akan membutuhkan pemijahan banyak proses, menonaktifkan / membersihkan cache dan terus berjalan sampai gagal.

Saya bahkan tidak yakin perilaku apa yang kami inginkan jika terjadi kesalahan ini.

Pertama-tama, masalah seharusnya tidak terjadi saat --no-cache aktif, karena cache tidak boleh diisi.
Kedua, saya tidak yakin dapat mencoba kembali operasi sinkronisasi dengan benar - apakah mungkin menggunakan writeFile() alih-alih writeFileSync() ? Dengan cara itu write-file-atomic harus mencoba lagi secara otomatis (Saya akan membuat tes untuk mengonfirmasi).

Pertama-tama, masalah seharusnya tidak terjadi saat --no-cache aktif, karena cache tidak boleh diisi.

Itu poin yang bagus, dan harus diperbaiki secara terpisah. Dengan begitu --no-cache setidaknya bisa menjadi solusi.

Kedua, saya tidak yakin dapat mencoba kembali operasi sinkronisasi dengan benar - apakah mungkin menggunakan writeFile() alih-alih writeFileSync() ?

Pikiran @cpojer tentang membuatnya tidak sinkron? Tidak yakin bagaimana skala itu. Atau jika Anda memiliki ide lain tentang cara memperbaikinya

• --no-cache sebenarnya lebih seperti --reset-cache . Artinya itu tidak akan menggunakan cache yang ada, tetapi masih akan menulis cache. Saya ingin mempertahankannya.
• Operasi ini harus disinkronkan, karena terjadi selama panggilan require dalam kode pengguna, jadi kami tidak dapat mengubahnya.

Ini repro lainnya dengan worker-farm dan write-file-atomic : https://github.com/asapach/write-atomic-issue

Temuan sejauh ini: versi sinkronisasi gagal seperti yang diharapkan, tetapi yang mengejutkan versi asinkron juga gagal. Ini berarti bahwa mereka mungkin menerapkan antrian coba lagi hanya ketika berjalan dalam proses yang sama, yang tidak membantu dalam kasus kami.

Saya ingin mempertahankannya.

Bendera baru? Itu nama yang sangat menyesatkan. Dan misalnya CI Anda jarang menginginkan cache, jadi itu hanya membuang-buang sumber daya. Atau apakah cache yang dibuat dalam satu kali pengujian digunakan selama --no-cache , dan hanya mengabaikan cache yang ada?

Ini repro lainnya dengan worker-farm dan write-file-atomic

Hebat! Bisakah Anda membuka masalah terhadap write-file-atomic? Rasanya seperti perbaikan harus dilakukan di sana, dan jika tidak (mereka tidak ingin mendukung banyak proses penulisan sekaligus) kami dapat mengunjungi kembali di pihak kami. WDYT?

Tambalan yang saya coba secara lokal yang tampaknya berfungsi mengabaikan kesalahan jika itu berasal dari mencoba mengganti nama ke file dengan konten yang sama. Karena itu hanya berarti proses lain 'memenangkan' perlombaan, kita dapat mengabaikannya dan melanjutkan.

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 , tentu, saya akan mengajukan masalah.

@cpojer , dapatkah kesalahan ini ditelan / diabaikan dan diperlakukan sebagai peringatan? Ini menyiratkan bahwa file telah ditulis dan tidak ada data yang hilang.

Masalah upstream: npm / write-file-atomic # 28

Saya pikir ini berarti "rename" bukanlah operasi atomik di Windows, jadi ini melanggar asumsi yang dibuat oleh write-file-atomic . Kecuali jika ada bendera yang dapat diaktifkan pada level API Windows, ini berarti tidak mungkin untuk memiliki penulisan / penggantian nama pada Windows sama sekali.

@jwbay solusi Anda terlihat masuk akal bagi saya! 👍 Alih-alih menggunakan indexOf , saya akan menggunakan e.code === 'EPERM' (lebih kuat, tidak bergantung pada pesan tertentu). Saya rasa kita tidak perlu membaca file itu lagi untuk memeriksa nilainya, karena ini bisa menimbulkan masalah konkurensi tambahan (mis. Jika file sedang ditulis oleh proses lain pada saat yang sama). Maukah Anda mengirimkan PR?

Saya baru saja akan mulai mengerjakan PR seharga write-file-atomic sepanjang baris "jika kita diminta untuk menulis sinkronisasi file tapi sudah dalam antrian untuk ditulis async, bail out" (mungkin dengan opsi untuk mengaktifkan perilaku). Tetapi jika kami senang menangani ini di level Jest, saya tidak akan terburu-buru. cc @ jeanlauli

Saya akan mulai mengerjakan PR untuk write-file-atomic di sepanjang baris "jika kita diminta untuk menulis sinkronisasi file tapi sudah dalam antrian untuk ditulis async, bail out" (mungkin dengan opsi untuk aktifkan perilakunya).

Saya pikir menambahkan logika ini (antrian lokal) tidak akan memperbaiki masalah, karena sebagian besar terjadi ketika proses yang berbeda mencoba menulis ke (mengganti nama) file yang sama.

Untuk memperbaiki masalah konkurensi sekali dan untuk selamanya, kita mungkin harus mempertimbangkan kembali bagaimana kita melakukan caching, misalnya memiliki satu proses yang mengakses cache, yang dengannya kita berkomunikasi melalui beberapa jenis IPC. Sistem penyimpanan kunci / nilai yang ada mungkin berguna, seperti memcached .

Saya pikir menambahkan logika ini (antrian lokal) tidak akan memperbaiki masalah, karena sebagian besar terjadi ketika proses yang berbeda mencoba menulis ke (mengganti nama) file yang sama.

Ah, saya mungkin salah paham tentang masalah ini. Cara saya membacanya, pustaka sudah memiliki mekanisme antrian yang berfungsi dengan baik untuk permintaan asinkron, tetapi jika Anda mencampur permintaan sinkronisasi _secara baik_ Anda bisa mendapatkan benturan.

Permintaan tarik saya yang direferensikan di atas seharusnya menyelesaikan masalah ini. Setidaknya itu berhasil untuk saya!

@mekwall , saya pikir mereka menggunakan rename() dalam versi asinkron writeFile() , dan masih gagal dalam pengujian saya: https://github.com/asapach/write-atomic-issue. Bisakah Anda mencoba menjalankan repro saya? Saya pikir perubahan Anda mungkin meminimalkan kemungkinan masalah ini terjadi, tetapi tidak menghilangkannya sepenuhnya.

@asapach Apakah Anda mencoba dengan perubahan saya? Karena saya mencoba beberapa kali, dan saya tidak pernah mendapatkan EPERM: operation not permitted, rename dengan perubahan saya sementara mendapatkannya setiap kali tanpa.

@mekwall , ya, masih gagal dengan perubahan Anda (meskipun asinkron). (Dikoreksi di bawah.)

Atau lebih tepatnya secara teknis, itu tidak gagal (karena aliran sinkronisasi tidak terganggu), tetapi konsol masih dipenuhi dengan kesalahan EPERM.

@asapach Saya menemukan masalah yang Anda alami. Ada di polyfill graceful-fs . Saya telah memposting perbaikan dalam PR ini: https://github.com/isaacs/node-graceful-fs/pull/119

@mekwall , ya ini tampaknya mengatasi masalah - tidak ada lagi kesalahan dalam versi sinkronisasi dan asinkron.
Masalahnya sekarang adalah file temporer tidak dihapus, karena fs.unlinkSync(tmpfile) tidak pernah dipanggil: https://github.com/npm/write-file-atomic/pull/29/files#diff -168726dbe96b3ce427e7fedce31bb0bcR198

@asapach Saya menambahkan unlink ke graceful-fs rename, tapi saya tidak yakin apakah itu cara yang benar. Afaik fs.rename menggunakan fungsi MoveFile dan seharusnya tidak menyalin sumber ke tujuan. Sumber seharusnya hanya mengubah nama dan sumber serta tujuan tidak boleh ada pada waktu yang bersamaan.

@mekwall , itu sedikit membantu, tetapi dalam beberapa kasus jika pekerja dihentikan lebih awal (karena semua pekerjaan telah selesai), beberapa file tidak dibersihkan, karena tidak menunggu pembersihan. Versi asinkron sepertinya berfungsi dengan baik.

@asapach Ini tidak bekerja seperti yang diharapkan sama sekali. Saya perlu menyelami bagian dalam node untuk mencari tahu bagaimana sebenarnya itu bekerja dan apa perilaku yang seharusnya. Saya percaya inti dari graceful-fs adalah membuatnya berfungsi sama di setiap platform, jadi saya akan menggali lebih dalam. Setidaknya kami telah menemukan pelakunya :)

@asapach Saya menyadari bahwa PR saya untuk write-file-atomic tidak akan berfungsi, jadi saya mengambil pendekatan lain dengan menambahkan fs.renameSync dalam graceful-fs dengan cara kerja yang sama seperti fs.rename tapi memblokir. Ini membuat tes Anda berfungsi seperti yang diharapkan!

@mekwall , Terima kasih, saya telah memverifikasi perubahan Anda pada kedua kasus repro saya dan tidak ada yang gagal.
Saya pikir sisi negatifnya saya melihat peningkatan penggunaan CPU dan disk untuk sinkronisasi, tetapi mungkin itu diharapkan.

Terima kasih banyak orang untuk mengambil ini dan membantu memperbaikinya. Sangat dihargai! ❤️ Semoga perbaikan di graceful-fs benar, dan ini akan dirilis.

@SimenB Sama- sama! Kami sedih dengan ini di tempat kerja jadi saya punya waktu untuk menyelidikinya oleh tim saya. Perubahan akan mempengaruhi banyak paket sehingga kemungkinan besar akan membutuhkan waktu bagi mereka untuk menerimanya: /

Adakah ide kapan solusi ini akan berhasil dirilis?

@cpojer dapatkah Anda memberikan info lebih lanjut mengapa ditutup? apakah ada perbaikan yang disediakan? Kami masih memiliki masalah ini

Maaf, sepertinya perbaikannya belum mendarat dengan anggun-fs :(

Dapatkah beberapa orang mengonfirmasi bahwa menggunakan https://github.com/isaacs/node-graceful-fs/pull/119 memperbaiki masalah mereka?

Anda dapat menggunakan garpu dengan menggunakan resolusi benang, lihat https://yarnpkg.com/en/docs/selective-version-resolutions , yang memungkinkan Anda menerapkan perbaikan ke CI, dll.

misalnya

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

@SimenB Ini memecahkan masalah bagi saya, setidaknya 😄

+1 Untuk saya juga.

@SimenB Juga memperbaiki masalah saya dan saya sekarang dapat menggunakan jest 22 di windows. (Kami terjebak di 20 sebelum ini).

Sunting: Sebenarnya, ini berfungsi di laptop dev saya, tetapi tidak berfungsi di server build. Ini menjalankan benang 1.2.1, mungkin itu sebabnya?

[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)

Yarn 1.0.0 seharusnya sudah cukup, namun patut dicoba untuk diupgrade

Baru saja mencoba memasukkan resolusi tetapi masih gagal untuk saya. Namun saya memiliki pelanggaran ENOENT dan EPERM:

    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)

dan

    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 Apakah server build Anda menjalankan Windows? Karena perbaikan di graceful-fs hanya akan menargetkan Windows, tetapi seharusnya tidak terjadi pada OS berbasis Linux.

@mekwall ya, windows - tapi itu windows server 2012 R2

Ini adalah masalah besar bagi saya dan tidak ada yang terjadi dengan graceful-fs sejak November 2016 dari apa yang saya lihat. Jadi saya cukup pesimis bahwa perbaikan @mekwall yang disediakan tidak akan digabungkan dalam waktu dekat. Apakah ada solusi sementara yang dapat kami gunakan selain tanda -i dan penyelesaian masalah?

Apakah --runInBand tidak berfungsi untuk Anda @frenic?

Itu sama dengan -i dan ya, itu berhasil. Tapi sayangnya itu tidak berkelanjutan dalam jangka panjang untuk proyek yang lebih besar.

Saya kira kami dapat membuat garpu dan menerbitkan milik kami sendiri, tetapi tampaknya perbaikan tersebut tidak berhasil untuk semua orang

Saya menghadapi situasi yang sama, tetapi dalam kasus saya, --runInBand tidak berfungsi.

Saya telah memeriksa graceful-fs override dengan versi terbaru Jest dan sayangnya sepertinya tidak lagi berfungsi dengan andal sejak saya terakhir mengujinya. Masih ada kemungkinan tidak nol bahwa itu mengalami kondisi balapan di suite pengujian besar.

Setelah menelusuri utas ini, saya menemukan resolusi menggunakan yarn . Apakah ada resolusi yang menggunakan npm sebagai gantinya?

Kami cukup beruntung sejauh ini hanya dengan menambahkan versi patch dari graceful-fs ke package.json kami. Bekerja untuk kami dengan npm dan benang.

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

Hai,

Untuk beberapa alasan kami hanya mendapatkan kesalahan ini saat menjalankan dari Jenkins, bukan saat dijalankan secara lokal (bahkan di mesin / folder yang sama, dll.)
Solusi @jsheetzati bekerja untuk kami juga (menggunakan npm), tapi bagaimanapun juga ini adalah tambalan. Apakah ada ETA untuk menyelesaikan ini secara permanen?

Terima kasih,
Mor

Kami juga memiliki masalah ini saat menjalankan lelucon dari Jenkins. --runInBand option membantu menghindari kegagalan selama eksekusi pekerjaan tunggal tetapi lelucon masih gagal saat menjalankan beberapa build secara paralel.
Sebagai solusinya kami menggunakan plugin sumber daya yang dapat dikunci untuk memastikan bahwa hanya satu proses jest yang dijalankan pada saat yang sama menjaga opsi --runInBand .
Semoga komentar ini bermanfaat bagi seseorang.

@nyrkovalex Apa yang kami lakukan untuk menghindari masalah yang Anda gambarkan adalah menggunakan opsi direktori cache Jest untuk memastikan cache tidak dibagikan ke seluruh ruang kerja.

Kami melakukannya dengan menerbitkan preset Jest yang menetapkan cacheDirectory: '<rootDir>/.jest-cache' dan memastikan bahwa semua paket menggunakannya. Jika melakukannya pastikan untuk menambahkan .jest-cache ke .gitignore .

Sebelum menambahkan opsi itu, kami akan mengalami beberapa masalah karena memiliki cache Jest global yang dibagikan ke 16 pelaksana per agen Jenkins. Menggunakan sumber daya yang dapat dikunci juga akan mencegah masalah seperti yang Anda sebutkan tetapi sia-sia karena Anda tidak menggunakan agen Jenkins secara maksimal (karena pengujian Jest menjadi hambatan).

@ anescobar1991 Opsi itu jelas merupakan solusi yang lebih baik, kami akan mempertimbangkan untuk menggunakannya.
Terima kasih atas tipnya!

Hai,

kami menggunakan gradle untuk menjalankan npm (jangan tanya mengapa :)) dan kombinasinya dengan Jenkins sangatlah mematikan.
Kami sudah mencoba:

1. mengatur cache agar berada di direktori lokal alih-alih cache global
2. menggunakan --runInBand
3. hanya satu pekerjaan yang berjalan di agen- tidak ada pekerjaan paralel
4. menjalankan uji gradle --max-pekerja 1 (dan tidak menggunakan --parallel)

Semua gagal dengan kesalahan yang sama.
Satu-satunya solusi yang berhasil untuk kami adalah solusi oleh @jsheetzati - Saya berharap ini diperbaiki secara resmi.

Kami mungkin bisa bercabang dan menerbitkan dengan perbaikan itu

itu akan luar biasa ...

Saya memiliki banyak masalah ini dan tambalan untuk fs anggun bekerja untuk saya. Jadi saya sangat menghargai perbaikan ini.

Sebagai solusi untuk mengutak-atik anggun-fs, tidak bisakah Anda memberikan setiap proses / utas pekerja direktori cache itu sendiri untuk menghindari kondisi balapan?

Mungkin lambat, tetapi kami harus menggunakan --runInBand di server CI kami dan itu jauh lebih buruk.

Jika seseorang dapat mengarahkan saya ke file yang tepat untuk dilihat, saya bahkan mungkin mencoba menulis tambalan. Saya benar-benar kesulitan mencari sumber lelucon.

Saya tidak yakin apa itu tetapi sudah beberapa minggu mungkin beberapa bulan dan saya tidak melihat kegagalan lagi. Kami telah menggunakan lelucon 22.4.2 untuk sementara dan meningkatkan ke 22.4.4 baru-baru ini. Kami juga telah memperbarui berbagai paket lainnya.

hanya untuk menyela - Saya melihat ini dengan lelucon 23.6 pada server windows Jenkins CI.

• --runInBand berfungsi, tetapi menggandakan waktu pengujian, jadi ini tidak bagus, dan karena kami menjalankan pengujian sebelum push, saya tidak dapat mengaktifkan ini tanpa membuat anggota tim saya sangat sedih
• penimpaan anggun-fs di package.json , seperti yang disebutkan oleh @jsheetzati (https://github.com/facebook/jest/issues/4444#issuecomment-370533355) berfungsi, tetapi ini sedikit

Karena graceful-fs tidak berbuat banyak tentang ini (https://github.com/isaacs/node-graceful-fs/pull/131 belum melihat tindakan sejak Juli tahun lalu), mungkin sudah waktunya untuk bercabang ? Saya telah menambahkan komentar cerewet di sana, tetapi saya tidak berharap itu akan membuat siapa pun tiba-tiba melompat untuk menyelesaikan masalah ini) ':

Saya mengalami masalah yang sama tetapi pesan kesalahannya berbeda
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

Tampaknya menjalankan lelucon dengan --runInBand tidak menyelesaikan masalah untuk pertama kalinya, tetapi hanya setelah menjalankan yang lain, ia dijalankan tanpa kesalahan.

Berjalan di Windows 10 Enterprise VM sebagai bagian dari TFS Build.

@EthanSankin bisakah Anda menguji dengan PR anggun-fs yang ditautkan juga?

Saya sedang mengerjakan pengganti graceful-fs yang seharusnya menyelesaikan masalah ini. Saat ini dalam versi alfa tetapi akan sangat bagus untuk mendapatkan beberapa pengadopsi awal: https://github.com/mekwall/normalized-fs

Mengembalikan ke versi lama tulis-file-atomic memecahkan masalah.

@moizgh dari versi apa ke versi apa?

@moizgh dari versi apa ke versi apa?

2.4.2 hingga 2.3.0

@iarna sepertinya ada regresi diperkenalkan.

Juga mengalami masalah ini, apakah ada wawasan tentang perbaikan yang lebih baik / permanen?

Ini dimulai lagi untuk kami dalam beberapa bulan terakhir - jendela - sangat terputus-putus.

write-file-atomic tidak lagi menggunakan graceful-fs - mungkin ada hubungannya dengan itu?