Jest: مخبأ كتابة حالة السباق عبر العمليات

لا يرتبط هذا؟ https://github.com/facebook/jest/pull/4432

لا أصدق ذلك. أعتقد أن الحالة التي نراها في الريبو الخاص بنا هي نفس الملف الذي تم الاستهزاء به لعمليتين مختلفتين (أثناء التشغيل بالتوازي) مما يتسبب في فشل عملية الكتابة في ذاكرة التخزين المؤقت لأن إحدى العمليات تم قفل الملف. يبدو أن هذه التذكرة تتعلق أكثر بملفات مختلفة بنفس المحتويات. ليس لدينا أي من تلك الحالات في المستودعات التي نستضيفها والتي واجهتنا هذه المشكلة.

نواجه نفس المشكلة بشكل أساسي مع اختباراتنا. إحدى الطرق السهلة لإعادة الإنتاج هي إزالة المزاح cacheDirectory لفرض إنشاء ذاكرة التخزين المؤقت في التشغيل التالي.
"فشل اختبار مجموعة العمل

jest: failed to cache transform results in:

C: / myniceproject / src / jest-cache / jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b / 3f / settingsProvider_3f1439e55275a95cfdb3295
رسالة الفشل: EPERM: العملية غير مسموح بها ، أعد التسمية
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a958ecfdb2995'
->
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a958ecfdb7`

تواجه نفس المشكلة ولا تجد طريقة للتغلب عليها. Jest غير قابل للاستخدام بشكل أساسي بالنسبة لنا مثل هذا.

نحاول التحديث إلى 21.2.0 من 20.0.4 والآن لدينا الخطأ التالي على خوادم البناء الخاصة بنا:

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)

لدي الآن نفس اختبارات المشكلة معطلة بشكل عشوائي.

إذا أجريت الاختبارات بعلامة --runInBand ، فسيكون كل شيء على ما يرام كما هو متوقع.

يمكنني رؤية نفس المشكلة بشكل ثابت إلى حد ما:

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

jest 21.2.1
العقدة 6.11.1
نظام التشغيل Windows

--no-cache لا يساعد و jest-transform-cache لا يزال قيد الكتابة. الشيء الوحيد الذي يساعد هو --runInBand ، وهو بالكاد مقبول للمشاريع الكبيرة.

هل من شيء يمكننا القيام به للمساعدة في تشخيص المشكلة؟ هل يجب إنشاء حالة repro؟

هل هذا الخطأ حرج؟ هل يمكن التعامل معها كتحذير بدلاً من إنهاء مجموعة الاختبارات بأكملها؟ هل هناك طريقة للتراجع وإعادة المحاولة؟

وجود نموذج صغير سيكون رائعًا

ها هو ريبرو: https://github.com/asapach/jest-cache-issue/
يتم تشغيله بشكل فعال من خلال babel-jest لملء ذاكرة التخزين المؤقت للتحويل.
هذا فشل بالنسبة لي 80٪ من الوقت على جهازين مختلفين (Win8.1 و Win10).
إذا قمت بإزالة --no-cache فإنه يفشل بنسبة 100٪ من الوقت. إضافة --runInBand تنخفض النسبة إلى 0٪.

(بدافع الفضول ، حاول تشغيله في WSL على Win10 ولم تعد المشكلة قابلة للتكرار باستخدام Posix API)

هل هذا يحدث فقط على Windows؟ ليس لدي وصول إلى أجهزة Windows بخلاف الأجهزة الافتراضية ، لذلك ليس من الأسهل تصحيح الأخطاء بالنسبة لي ...

jeanlauliac لقد أضفت write-file-atomic في # 4088 ، هل ستتمكن من المساعدة؟

هذه المشكلة تشبه إلى حد بعيد https://github.com/npm/write-file-atomic/issues/10 و https://github.com/npm/write-file-atomic/pull/22.

قمت للتو بتشغيل تتبع

الوقت من اليوم | اسم العملية | PID | العملية | المسار | النتيجة | التفاصيل
- | - | - | - | - | - | -
16: 54: 43.2304011 | node.exe | 7624 | SetRenameInformationFile | ... \ Constant_ee286bbcf367680ce61a90e506522f92.82986661 | النجاح | ReplaceIfExists: صحيح ، اسم الملف: ... \ Constant_ee286bbcf367680ce61a90e506522f92
16: 54: 43.2305499 | node.exe | 8208 | SetRenameInformationFile | ... \ Constant_ee286bbcf367680ce61a90e506522f92.103872574 | رفض الوصول | ReplaceIfExists: صحيح ، اسم الملف: ... \ Constant_ee286bbcf367680ce61a90e506522f92

كما ترى ، هناك عمليتان تحاولان إعادة تسمية نفس الملف خلال 1 مللي ثانية من بعضهما البعض وفشل الآخر.

أعتقد أن npm / write-file-atomic # 22 يعالج الإصدار غير المتزامن لـ writeFile() ، لكن writeFileSync() لا يزال متأثرًا.

هل من الممكن إنشاء إعادة عرض توضح أن استخدام write-file-atomic في worker-farm مقابل الملف نفسه قد فشل بطريقة ما؟ سيكون من الرائع فتح مشكلة ضد هذا المشروع ، حيث أعتقد أن هذا هو المكان الذي يجب أن يكون فيه الإصلاح.

أو إذا كان بإمكانك كتابة اختبار داخل المزاح يُظهر نفس الخطأ (لدينا appveyor CI) الذي يمكن أن يكون بداية أيضًا؟

لست متأكدًا حتى من السلوك الذي نريده في حالة حدوث هذا الخطأ. إعادة محاولة الكتابة؟ أعد الاختبار؟ ملف الاختبار بأكمله؟

حسنًا ، سأحاول إنشاء نسخة أخرى. لست متأكدًا من إمكانية إنشاء اختبار دعابة ، لأنه سيتطلب إنشاء عمليات متعددة وتعطيل / تنظيف ذاكرة التخزين المؤقت والاستمرار في العمل حتى تفشل.

لست متأكدًا حتى من السلوك الذي نريده في حالة حدوث هذا الخطأ.

حسنًا ، أولاً ، يجب ألا تحدث المشكلة حتى عندما يكون --no-cache قيد التشغيل ، حيث لا يجب ملء ذاكرة التخزين المؤقت.
ثانيًا ، لست متأكدًا من إمكانية إعادة محاولة عملية المزامنة بشكل صحيح - هل من الممكن استخدام writeFile() بدلاً من writeFileSync() ؟ بهذه الطريقة ، يجب إعادة المحاولة write-file-atomic تلقائيًا (سأقوم بإنشاء اختبار للتأكيد).

حسنًا ، أولاً ، يجب ألا تحدث المشكلة حتى عندما يكون --no-cache قيد التشغيل ، حيث لا يجب ملء ذاكرة التخزين المؤقت.

هذه نقطة جيدة ويجب إصلاحها بشكل منفصل. بهذه الطريقة يمكن أن يكون --no-cache حلاً على الأقل.

ثانيًا ، لست متأكدًا من إمكانية إعادة محاولة عملية المزامنة بشكل صحيح - هل من الممكن استخدام writeFile() بدلاً من writeFileSync() ؟

cpojer الأفكار حول جعلها غير متزامنة؟ لست متأكدا كيف أن المقاييس. أو إذا كان لديك فكرة أخرى حول كيفية إصلاح هذا

• --no-cache يشبه --reset-cache الواقع. هذا يعني أنه لن يستخدم ذاكرة التخزين المؤقت الحالية ، لكنه سيظل يكتب ذاكرة التخزين المؤقت. أود الاحتفاظ بذلك.
• يجب مزامنة هذه العمليات ، لأنها تحدث أثناء مكالمات require في كود المستخدم ، لذلك لا يمكننا تغيير ذلك.

إليك النسخة الأخرى مع worker-farm و write-file-atomic : https://github.com/asapach/write-atomic-issue

النتائج حتى الآن: فشل إصدار المزامنة كما هو متوقع ، ولكن من المدهش أن الإصدار غير المتزامن فشل أيضًا. هذا يعني أنهم ربما ينفذون قائمة انتظار لإعادة المحاولة فقط عندما يتم تشغيلها في نفس العملية ، وهذا لا يساعد في حالتنا.

أود الاحتفاظ بذلك.

علم جديد؟ إنه اسم مضلل للغاية. وعلى سبيل المثال ، نادرًا ما تريد ذاكرة التخزين المؤقت على أي حال ، لذا فهي مجرد موارد مهدرة. أو هل يتم إنشاء ذاكرة تخزين مؤقت خلال تشغيل اختباري واحد أثناء --no-cache ، وتتجاهل فقط ذاكرات التخزين المؤقت الموجودة؟

إليك النسخة الأخرى مع worker-farm و write-file-atomic

رائع! هل يمكنك فتح قضية ضد كتابة ملف-ذرة؟ يبدو أن الإصلاح يجب أن يذهب إلى هناك ، وإذا لم يكن كذلك (لا يريدون دعم عمليات متعددة الكتابة في وقت واحد) فيمكننا إعادة النظر من جانبنا. WDYT؟

التصحيح الذي جربته محليًا والذي بدا أنه يعمل يتجاهل الخطأ إذا كان ناتجًا عن محاولة إعادة تسمية ملف بنفس المحتوى. نظرًا لأنه يعني مجرد عملية أخرى "الفوز" بالسباق ، يمكننا تجاهلها والمضي قدمًا.

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 ، بالتأكيد ،

cpojer ، هل يمكن ابتلاع / تجاهل هذا الخطأ والتعامل معه كتحذير؟ هذا يعني أن الملف قد تمت كتابته بالفعل ولا ينبغي فقد أي بيانات.

مشكلة المنبع: npm / write-file-atomic # 28

أعتقد أن هذا يعني أن "إعادة التسمية" ليست عملية ذرية على Windows ، لذا فهي تكسر الافتراض الذي قدمه write-file-atomic . ما لم تكن هناك علامة يمكن تمكينها على مستوى واجهة برمجة تطبيقات Windows ، فقد يعني هذا أنه من المستحيل أن يكون لديك عمليات كتابة / إعادة تسمية ذرية على Windows تمامًا.

jwbay الحل الخاص بك يبدو معقولا بالنسبة لي! 👍 بدلاً من استخدام indexOf مع ذلك ، سأستخدم e.code === 'EPERM' (أكثر قوة ، لا يعتمد على رسالة محددة). لا أعتقد أنه يجب علينا قراءة الملف مرة أخرى للتحقق من القيمة ، لأن هذا قد يؤدي إلى مشكلات إضافية تتعلق بالتزامن (على سبيل المثال ، إذا تمت كتابة الملف بواسطة عملية أخرى في نفس الوقت). هل تمانع في إرسال PR من فضلك؟

كنت على وشك بدء العمل على PR مقابل write-file-atomic على غرار "إذا طُلب منا كتابة مزامنة ملف لكنها موجودة بالفعل في قائمة الانتظار ليتم كتابتها غير متزامن ، والإنقاذ" (ربما مع خيار لتبديل السلوك). ولكن إذا كنا سعداء للتعامل مع هذا على مستوى الدعابة ، فلن أستعجل. cc @ jeanlauliac

كنت على وشك أن أبدأ العمل على علاقات عامة لكتابة ملف - ذري على غرار "إذا طُلب منا كتابة مزامنة ملف ولكنها موجودة بالفعل في قائمة الانتظار ليتم كتابتها غير متزامنة ، يمكنك الإنقاذ" (ربما مع خيار تبديل السلوك).

أعتقد أن إضافة هذا المنطق (قائمة الانتظار المحلية) لن يحل المشكلة ، لأنه يحدث غالبًا عندما تحاول عمليات مختلفة الكتابة إلى (إعادة تسمية) نفس الملف.

لإصلاح مشكلات التزامن مرة واحدة وإلى الأبد ، قد نضطر إلى إعادة النظر في كيفية قيامنا بالتخزين المؤقت ، على سبيل المثال ، لدينا عملية واحدة تصل إلى ذاكرة التخزين المؤقت ، والتي نتواصل بها عبر نوع من IPC. قد تكون أنظمة تخزين المفاتيح / القيمة الحالية سهلة الاستخدام ، مثل memcached .

أعتقد أن إضافة هذا المنطق (قائمة الانتظار المحلية) لن يحل المشكلة ، لأنه يحدث غالبًا عندما تحاول عمليات مختلفة الكتابة إلى (إعادة تسمية) نفس الملف.

آه ، ربما أساءت فهم القضية بعد ذلك. بالطريقة التي قرأتها بها ، تحتوي المكتبة بالفعل على آلية قائمة انتظار تعمل بشكل جيد مع الطلبات غير المتزامنة ، ولكن إذا قمت بخلط طلبات المزامنة _كذلك_ يمكنك الحصول على تصادمات.

يجب أن يحل طلب السحب المشار إليه أعلاه هذه المشكلة. على الأقل فعلت ذلك من أجلي!

mekwall ، أعتقد أنهم يستخدمون rename() في الإصدار غير المتزامن من writeFile() ، وما زال يفشل في الاختبار: https://github.com/asapach/write-atomic-issue. هل يمكن أن تحاول تشغيل ريبرو الخاص بي من فضلك؟ أعتقد أن التغيير الذي أجريته قد يقلل من احتمالية حدوث هذه المشكلة ، لكنه لا يلغيها تمامًا.

asapach هل EPERM: operation not permitted, rename مع تغييراتي أثناء الحصول عليها في كل مرة بدونها.

mekwall ، نعم ، ما زلت تفشل في تغييراتك (رغم أنها غير متزامنة). (مصحح أدناه).

أو بالأحرى لا يفشل من الناحية الفنية (لأن تدفق المزامنة لا ينقطع) ، لكن وحدة التحكم لا تزال مليئة بأخطاء EPERM.

asapach لقد وجدت المشكلة التي تواجهها. إنه موجود في polyfill graceful-fs . لقد نشرت إصلاحًا في هذا العلاقات العامة: https://github.com/isaacs/node-graceful-fs/pull/119

mekwall ، نعم يبدو أن هذا يعالج المشكلة - لا مزيد من الأخطاء في كل من إصدارات المزامنة وغير المتزامنة.
المشكلة الآن هي أن ملفات temp لا تتم إزالتها ، لأن fs.unlinkSync(tmpfile) لا يُستدعى أبدًا: https://github.com/npm/write-file-atomic/pull/29/files#diff -168726dbe96b3ce427e7fedce31bb0bcR198

asapach أضفت إلغاء graceful-fs ، لكنني لست متأكدًا مما إذا كانت هذه هي الطريقة الصحيحة للذهاب. يستخدم Afaik fs.rename وظيفة MoveFile والتي يجب ألا تنسخ المصدر إلى الوجهة. يجب على المصدر فقط تغيير الاسم ويجب ألا يتواجد المصدر والوجهة في نفس الوقت.

mekwall ، هذا يساعد قليلاً ، ولكن في بعض الحالات إذا تم إنهاء العامل مبكرًا (لأن كل العمل قد تم) ، لا يتم تنظيف بعض الملفات ، نظرًا لأنه لا ينتظر التنظيف. يبدو أن الإصدار غير المتزامن يعمل بشكل جيد.

asapach لا يعمل كما هو متوقع على الإطلاق. أحتاج إلى الغوص في الأجزاء الداخلية للعقدة لمعرفة كيف تعمل بالفعل وماذا يجب أن يكون السلوك المقصود. أعتقد أن بيت القصيد من graceful-fs هو جعلها تعمل بنفس الطريقة على كل منصة ، لذا سأبحث أكثر في ذلك. على الأقل وجدنا الجاني :)

asapach أدركت أن العلاقات العامة الخاصة بي مقابل write-file-atomic لن تعمل ، لذلك اتخذت طريقة أخرى بإضافة fs.renameSync في graceful-fs بنفس الحلول مثل fs.rename لكن المنع. هذا يجعل اختبارك يعمل كما هو متوقع!

mekwall ، شكرًا ، لقد تحققت من تغييراتك في كل من حالات repro الخاصة بي ولم يفشل أي منها.
أعتقد أن الجانب السلبي أرى زيادة استخدام وحدة المعالجة المركزية والقرص للمزامنة ، ولكن من المتوقع أن يحدث ذلك.

شكرًا جزيلاً للناس على انتقاء هذا الأمر والمساعدة في إصلاحه. مقدر جدا! ❤️ نأمل أن يكون الإصلاح في graceful-fs هو الإصلاح الصحيح ، ويتم تحريره.

SimenB على الرحب والسعة! لقد تألمنا من هذا في العمل لذلك لدي بعض الوقت للتحقيق في هذا من قبل فريقي. ستؤثر التغييرات على الكثير من الحزم ، لذا من المرجح أن يستغرق قبولها بعض الوقت: /

هل لديك أي فكرة عن موعد وصول هذا الحل إلى إصدار؟

cpojer هل يمكنك تقديم المزيد من المعلومات لماذا تم إغلاقه؟ هل يوجد حل متوفر؟ لا يزال لدينا هذه المشكلة

معذرة ، يبدو أن الإصلاح لم يصل إلى رشيقة حتى الآن :(

هل يستطيع العديد من الأشخاص تأكيد أن استخدام https://github.com/isaacs/node-graceful-fs/pull/119 يعمل على إصلاح مشكلاتهم؟

يمكنك استخدام الشوكة باستخدام دقة الخيوط ، راجع https://yarnpkg.com/en/docs/selective-version-resolutions ، والتي من المفترض أن تسمح لك بنشر الإصلاح على CI وما إلى ذلك.

على سبيل المثال

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

SimenB إنه يحل المشكلة بالنسبة لي ، على الأقل 😄

+1 بالنسبة لي أيضًا.

SimenB قام أيضًا

تحرير: في الواقع ، لقد عملت على جهاز الكمبيوتر المحمول الخاص بي ، لكنها لم تعمل على خادم الإنشاء. إنها خيوط تعمل 1.2.1 ، ربما هذا هو السبب؟

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

يجب أن يكون الغزل 1.0.0 كافيًا ، يستحق محاولة الترقية

حاولت للتو وضع القرار لكنها ما زالت تفشل بالنسبة لي. ومع ذلك ، لدي انتهاكات ENOENT و 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)

و

    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 هل يعمل خادم graceful-fs ستستهدف Windows فقط ، لكن لا يجب أن يحدث ذلك على نظام تشغيل Linux.

mekwall نعم ، windows - لكنها Windows Server 2012 R2

هذه مشكلة كبيرة بالنسبة لي ولم يحدث شيء مع graceful-fs منذ نوفمبر 2016 لما يمكنني رؤيته. لذلك أشعر بالتشاؤم الشديد لأن الإصلاح المقدم -i وحل الحل البديل؟

هل --runInBand لا يعمل من أجلكfrenic؟

هذا هو نفسه -i ونعم ، إنه يعمل. لكن لسوء الحظ ، لا يمكن استدامته على المدى الطويل للمشاريع الأكبر.

أعتقد أننا يمكن أن نتفرع وننشر ما يخصنا ، لكن لا يبدو أن الإصلاح يصلح للجميع

أنا أعاني من نفس الموقف ، لكن في حالتي ، لا يعمل --runInBand.

لقد تحققت من تجاوز graceful-fs مع أحدث إصدار من Jest ولسوء الحظ لم يعد يعمل بشكل موثوق منذ آخر مرة قمت باختباره. لا تزال هناك فرصة غير صفرية أن يتم تشغيله في حالة السباق في مجموعات الاختبار الكبيرة.

بعد التمرير خلال هذا الموضوع ، وجدت حلًا باستخدام yarn . هل هناك حل باستخدام npm بدلاً من ذلك؟

لقد كان حظنا جيدًا حتى الآن بإضافة الإصدار المصحح من graceful-fs إلى package.json الخاص بنا. يعمل لدينا مع npm والغزل.

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

مرحبا،

لسبب ما ، لا نحصل على هذا الخطأ إلا عند التشغيل من Jenkins ، وليس عند التشغيل محليًا (حتى على نفس الجهاز / المجلد وما إلى ذلك)
حل jsheetzati يعمل بالنسبة لنا أيضًا (باستخدام npm) ، لكنه تصحيح بعد كل شيء. هل هناك ETA لحل هذا بشكل دائم؟

شكر،
مور

لدينا أيضًا هذه المشكلة عند تشغيل الدعابة من Jenkins. يساعد الخيار --runInBand على تجنب الفشل أثناء تنفيذ مهمة واحدة ولكن الدعابة لا تزال تفشل عند تشغيل العديد من الإصدارات بالتوازي.
كحل بديل ، نستخدم مكونًا إضافيًا للموارد القابلة للقفل للتأكد من تنفيذ عملية jest واحدة فقط في نفس الوقت مع الاحتفاظ بخيار --runInBand .
آمل أن يكون هذا التعليق مفيدًا لشخص ما.

nyrkovalex ما نفعله لتجنب المشكلة التي تصفها هو استخدام خيار دليل ذاكرة التخزين المؤقت لـ Jest للتأكد من عدم مشاركة ذاكرة التخزين المؤقت عبر مساحات العمل.

نقوم بذلك عن طريق نشر إعداد Jest المسبق الذي يحدد cacheDirectory: '<rootDir>/.jest-cache' والتأكد من أن جميع الحزم تستخدمه. إذا كنت تفعل ذلك ، فتأكد من إضافة .jest-cache إلى .gitignore .

قبل إضافة هذا الخيار ، سنواجه العديد من المشكلات نتيجة وجود ذاكرة تخزين مؤقت Jest عالمية مشتركة بين 16 منفذًا لكل وكيل Jenkins. سيؤدي استخدام الموارد القابلة للقفل أيضًا إلى منع حدوث المشكلات كما ذكرت ، ولكنه يعد إهدارًا لأنك لا تستخدم وكيل Jenkins الخاص بك إلى أقصى إمكاناته (حيث تصبح اختبارات Jest عنق الزجاجة).

@ anescobar1991 هذا الخيار هو بالتأكيد حل أفضل ، سننظر في استخدامه.
شكرا للحصول على معلومات!

مرحبا،

نحن نستخدم gradle لتشغيل npm (لا تسأل لماذا :)) والجمع بين ذلك مع Jenkins هو أمر قاتل.
حاولنا:

1. تعيين ذاكرة التخزين المؤقت لتكون على الدليل المحلي بدلاً من ذاكرة التخزين المؤقت العامة
2. باستخدام --runInBand
3. فقط وظيفة واحدة تعمل على الوكيل - لا توجد وظائف موازية
4. تشغيل اختبار gradle - الحد الأقصى للعمال 1 (وليس باستخدام - بالتوازي)

كل فشل مع نفس الخطأ.
الحل الوحيد الذي يناسبنا هو jsheetzati - أتمنى أن يتم إصلاح هذا رسميًا.

ربما يمكننا أن نتفرع وننشر بهذا الإصلاح

سيكون هذا رائعا...

لدي هذه المشكلة كثيرًا وعمل التصحيح الخاص بـ fs الرشيق بالنسبة لي. لذلك سأكون ممتنا لهذا الإصلاح.

كحل بديل للعبث بـ graceful-fs ، ألا يمكنك ببساطة إعطاء كل عملية عامل / مؤشر ترابط دليل ذاكرة التخزين المؤقت الخاص به لتجنب حالة السباق؟

من المحتمل أن يكون الأمر بطيئًا ، ولكن علينا استخدام --runInBand على خادم CI الخاص بنا وهذا أسوأ بكثير.

إذا تمكن شخص ما من توجيهي إلى الملفات الصحيحة للنظر فيها ، فقد أحاول كتابة تصحيح. أجد صعوبة في التنقل بين مصدر الدعابة.

لست متأكدًا مما هو عليه ، لكن مرت أسابيع قليلة ربما شهرين ولم ألاحظ الفشل بعد الآن. لقد استخدمنا jest 22.4.2 لفترة من الوقت وقمنا بالترقية إلى 22.4.4 مؤخرًا. لقد قمنا أيضًا بتحديث حزم أخرى متنوعة.

فقط للمشاركة - أرى هذا مع 23.6 مازحة على خادم windows Jenkins CI.

• --runInBand يعمل ، لكنه يضاعف وقت الاختبار ، لذا فهو ليس رائعًا ، وبما أننا نجري اختبارات قبل الدفع ، لا يمكنني تمكين هذا دون جعل أعضاء فريقي حزينين للغاية
• يعمل تجاوز graceful-fs في package.json ، كما ورد في jsheetzati (https://github.com/facebook/jest/issues/4444#issuecomment-370533355) ، لكنه نوع من الاختراق.

نظرًا لأن graceful-fs لا يفعل الكثير حيال هذا (https://github.com/isaacs/node-graceful-fs/pull/131 لم يشهد أي إجراء منذ يوليو من العام الماضي) ، فربما حان الوقت للتشعب ؟ لقد أضفت تعليق تذمر هناك ، لكنني لا أتوقع أن يجعل أي شخص يقفز فجأة لفرز هذا) ':

أواجه نفس المشكلة ولكن رسالة الخطأ مختلفة
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

يبدو أن تشغيل المزاح مع --runInBand لا يحل المشكلة في المرة الأولى ، ولكن يتم تنفيذه بدون أخطاء إلا بعد تشغيله مرة أخرى.

يعمل على Windows 10 Enterprise VM كجزء من TFS Build.

EthanSankin هل يمكنك الاختبار مع العلاقات العامة المرتبطه كذلك؟

أنا أعمل على استبدال graceful-fs الذي يجب أن يحل هذه المشكلات. إنه حاليًا في إصدار ألفا ولكن سيكون من الرائع الحصول على بعض المستخدمين الأوائل: https://github.com/mekwall/normalized-fs

بالعودة إلى الإصدار الأقدم من كتابة الملف ، حل المشكلة.

moizgh من أي إصدار إلى أي إصدار؟

moizgh من أي إصدار إلى أي إصدار؟

2.4.2 إلى 2.3.0

iarna يبدو أنه تم تقديم سوم الانحدار.

تواجه أيضًا هذه المشكلة ، هل لديك أية أفكار حول إصلاح أفضل / دائم؟

بدأ هذا مرة أخرى بالنسبة لنا في الشهرين الماضيين - النوافذ - متقطع للغاية.

لم يعد write-file-atomic يستخدم رشيقة fs - ربما هذا له علاقة به؟