Jest: कैश प्रक्रियाओं के दौरान दौड़ की स्थिति लिखते हैं

क्या यह संबंधित नहीं है? https://github.com/facebook/jest/pull/4432

मैं ऐसा नहीं मानता। मेरा मानना ​​है कि जिस मामले को हम अपने रेपो में देखते हैं, वही सटीक फ़ाइल है जो 2 अलग-अलग प्रक्रियाओं (समानांतर में चलने के दौरान) के लिए मज़ाक उड़ाती है जिसके कारण कैश राइट ऑपरेशन विफल हो जाता है क्योंकि एक प्रक्रिया में फ़ाइल लॉक होती है। ऐसा लगता है कि टिकट समान सामग्री वाली विभिन्न फ़ाइलों के बारे में अधिक है। हमारे पास उन मामलों में से कोई भी नहीं है जिनके भंडार में हम होस्ट करते हैं कि हम इस मुद्दे पर भागे।

हम मूल रूप से अपने परीक्षणों के साथ एक ही मुद्दे में भाग लेते हैं। पुन: उत्पन्न करने का एक आसान तरीका यह था कि अगले रन पर कैश जनरेशन को मजबूर करने के लिए jest cacheDirectory को हटाया जाए।
`` `टेस्ट सूट चलाने में विफल रहा

jest: failed to cache transform results in:

सी: / myniceproject / src / हंसी-कैश / हंसी-परिणत-संचय-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b / 3F / settingsProvider_3f1439e55275a95ecfdb7dcb432f7958
विफलता संदेश: EPERM: संचालन की अनुमति नहीं है, नाम बदलें
'C: \ myniceproject \ srcjest-cachejest-परिणत-संचय-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3F \ settingsProvider_3f1439e55275a95ecfdb7dcb432f7958.1630729137'
->
'C: \ myniceproject \ srcjest-cachejest-परिणत-संचय-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3F \ settingsProvider_3f1439e55275a95ecfdb7dcb432f7958'`

एक ही समस्या होने और इसके आसपास कोई रास्ता नहीं मिल सकता है। जेस्ट मूल रूप से हमारे लिए इस तरह अनुपयोगी है।

हम 20.0.4 से 21.2.0 को अपडेट करने की कोशिश कर रहे हैं और अब हमारे बिल्ड सर्वर पर निम्नलिखित त्रुटि है:

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)

जेस्ट 21.2.1
नोड 6.11.1
ओएस विंडोज

--no-cache मदद नहीं करता है और jest-transform-cache अभी भी लिखा जा रहा है। केवल एक चीज जो मदद करती है वह है --runInBand , जो बड़ी परियोजनाओं के लिए शायद ही स्वीकार्य हो।

समस्या का निदान करने में सहायता के लिए हम कुछ भी कर सकते हैं? क्या मुझे रेप केस बनाना चाहिए?

क्या यह त्रुटि महत्वपूर्ण है? क्या इसे पूरे टेस्ट सूट को लेने के बजाय एक चेतावनी के रूप में माना जा सकता है? क्या पीछे हटने और पीछे हटने का कोई तरीका है?

एक छोटे से रिप्रो होने से बहुत अच्छा होगा

यहां देखें रिप्रो:
यह प्रभावी रूप से ट्रांसफ़ॉर्म कैश को पॉप्युलेट करने के लिए babel-jest माध्यम से लॉश-एसस चलाता है।
यह मेरे लिए दो अलग-अलग मशीनों (Win8.1 और Win10) पर 80% समय के लिए विफल रहता है।
यदि आप --no-cache निकालते हैं तो यह 100% समय विफल हो जाता है। --runInBand जोड़ने से यह 0% तक नीचे आ जाता है।

(जिज्ञासा से बाहर Win10 पर WSL में इसे चलाने की कोशिश की और पॉज़िक्स एपीआई का उपयोग करके समस्या पुन: पेश करने योग्य नहीं है)

क्या यह सिर्फ विंडोज पर हो रहा है? मेरे पास वर्चुअल मशीनों से परे विंडोज़ मशीनों तक पहुंच नहीं है, इसलिए मेरे लिए डीबग करना सबसे आसान नहीं है ...

@jeanlauliac को आपने # 4088 में write-file-atomic जोड़ा, क्या आप मदद कर पाएंगे?

यह समस्या https://github.com/npm/write-file-atomic/issues/10 और https://github.com/npm/write-file-atomic/pull/22 के समान है

बस एक सामन ट्रेस चला, यहाँ इस मुद्दे का एक उदाहरण है:

दिन का समय | प्रक्रिया का नाम | पीआईडी ​​| ऑपरेशन | पथ | परिणाम | विस्तार
- | - | - | - | - | - | -
16: 54: 43.2304011 | नोड। exe | 7624 | SetRenameInformationFile | ... \ निरंतर_ee286bbcf367680ce61a90e506522f92.82986661 | सफलता | रिप्लेसआईफ़िस्ट्स: ट्रू, फाइलनेम: ... \ स्थाई_ee286bbcf367680ce61a90e506522f92
16: 54: 43.2305499 | नोड। exe | 8208 | SetRenameInformationFile | ... \ स्थिर_ee286bbcf367680ce61a90e506522f92.103872574 | प्रवेश अस्वीकृत | रिप्लेसआईफ़िस्ट्स: ट्रू, फाइलनेम: ... \ स्थाई_ee286bbcf367680ce61a90e506522f92

जैसा कि आप देख सकते हैं कि दो प्रक्रियाएं एक दूसरे के 1ms के भीतर एक ही फ़ाइल का नाम बदलने की कोशिश कर रही हैं और दूसरा विफल रहता है।

मुझे लगता है कि npm / write-file-atomic # 22 writeFile() के async संस्करण को संबोधित करता है, लेकिन writeFileSync() अभी भी प्रभावित है।

क्या यह दर्शाना एक रेप्रो बनाना संभव होगा कि सिर्फ write-file-atomic का उपयोग करके worker-farm उपयोग किसी भी तरह से विफल न हो? उस परियोजना के खिलाफ एक मुद्दा खोलने के लिए बहुत अच्छा होगा, जैसा कि मुझे लगता है कि जहां ठीक होना चाहिए।

या यदि आप जेस्ट के भीतर एक परीक्षण लिख सकते हैं जो एक ही त्रुटि दिखाता है (हमारे पास एपी है) तो यह एक शुरुआत भी हो सकती है?

मुझे यह भी निश्चित नहीं है कि इस त्रुटि के मामले में हम क्या व्यवहार चाहते हैं। लेखन को फिर से लें? परीक्षण फिर से करें? पूरी परीक्षा फ़ाइल?

ठीक है, मैं एक और रिप्रो बनाने की कोशिश करूँगा। सुनिश्चित नहीं है कि यह एक जेस्ट टेस्ट बनाना संभव है, क्योंकि इसमें कैश को अक्षम / साफ़ करने और इसे विफल होने तक चालू रखने के लिए कई प्रक्रियाओं की आवश्यकता होगी।

मुझे यह भी निश्चित नहीं है कि इस त्रुटि के मामले में हम क्या व्यवहार चाहते हैं।

खैर, सबसे पहले मुद्दा तब भी नहीं होना चाहिए जब --no-cache चालू हो, क्योंकि कैश को आबाद नहीं किया जाना चाहिए।
दूसरे, मुझे यकीन है कि यह समन्वयन कार्रवाई ठीक से फिर से प्रयास करना संभव है नहीं कर रहा हूँ - यह उपयोग करना संभव है writeFile() के बजाय writeFileSync() ? इस तरह write-file-atomic को अपने आप पुनर्प्रयास करना चाहिए (मैं पुष्टि करने के लिए एक परीक्षण बनाऊंगा)।

खैर, सबसे पहले मुद्दा तब भी नहीं होना चाहिए जब --no-cache चालू हो, क्योंकि कैश को आबाद नहीं किया जाना चाहिए।

यह एक अच्छा बिंदु है, और इसे अलग से तय किया जाना चाहिए। इस तरह --no-cache कम से कम वर्कअराउंड हो सकता है।

दूसरे, मुझे यकीन है कि यह समन्वयन कार्रवाई ठीक से फिर से प्रयास करना संभव है नहीं कर रहा हूँ - यह उपयोग करना संभव है writeFile() के बजाय writeFileSync() ?

@ इसे बनाने के बारे में विचार नहीं सिंक? यकीन नहीं होता कि कैसे तराजू। या यदि आप इसे ठीक करने के बारे में एक और विचार है

• --no-cache --reset-cache वास्तव में
• इन ऑपरेशनों को सिंक करना होगा, क्योंकि वे उपयोगकर्ता कोड में require कॉल के दौरान होते हैं, इसलिए हम इसे बदल नहीं सकते हैं।

यहाँ worker-farm और write-file-atomic साथ अन्य रेप्रो है: https://github.com/asapach/write-atomic-issue

अब तक की खोजें: सिंक संस्करण अपेक्षा के अनुरूप विफल रहता है, लेकिन आश्चर्यजनक रूप से async संस्करण भी विफल रहता है। इसका मतलब यह है कि वे संभवत: एक ही प्रक्रिया में चलने पर ही एक रिट्री कतार लागू करते हैं, जो हमारे मामले में मदद नहीं करता है।

मैं उसे बनाए रखना चाहूंगा।

नया झंडा? यह एक बेहद भ्रामक नाम है। और उदाहरण के लिए CI पर आप शायद ही कभी भी कैश चाहते हैं, इसलिए यह सिर्फ संसाधनों की बर्बादी है। या --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 / राइट-फाइल-एटॉमिक # 28

मुझे लगता है कि इसका अर्थ है "नाम बदलना" विंडोज पर एक परमाणु ऑपरेशन नहीं है, इसलिए यह write-file-atomic द्वारा की गई धारणा को तोड़ता है। जब तक विंडोज एपीआई स्तर पर एक ध्वज सक्षम किया जा सकता है, इसका मतलब यह हो सकता है कि विंडोज पर परमाणु लिखना / नाम बदलना पूरी तरह से असंभव है।

@jwbay आपका समाधान मुझे उचित लगता है! I'd indexOf का उपयोग करने के बजाय, मैं e.code === 'EPERM' उपयोग करता हूं (अधिक मजबूत, किसी अन्य संदेश पर निर्भर नहीं करता)। मुझे नहीं लगता कि मूल्य को जांचने के लिए हमें फिर से फ़ाइल को पढ़ना चाहिए, क्योंकि यह अतिरिक्त संगामिति मुद्दों को पेश कर सकता है (उदाहरण के लिए यदि फ़ाइल उसी समय एक और प्रक्रिया द्वारा लिखी जा रही है)। क्या आप पीआर भेजना चाहेंगे, कृपया?

मैं एक पीआर पर write-file-atomic "की तर्ज पर काम शुरू करने वाला था" अगर हमें एक फाइल सिंक लिखने के लिए कहा जाता है, लेकिन यह कतार में पहले से ही async लिखा जा सकता है, तो बाहर हो सकता है "(शायद एक विकल्प के साथ व्यवहार को चालू करने के लिए)। लेकिन अगर हम जेस्ट स्तर पर इसे संभालने के लिए खुश हैं, तो मैं जल्दी नहीं करूंगा। cc @jeanlauliac

मैं लिखने के बारे में पीआर-फाइल-एटॉमिक के लिए "अगर हम एक फ़ाइल सिंक लिखने के लिए कहा जाता है, लेकिन यह पहले से ही कतार में है async लिखा जा रहा है, जमानत के लिए" के बारे में काम शुरू करने वाला था (शायद एक विकल्प के साथ व्यवहार पर स्विच करें)।

मुझे लगता है कि इस तर्क (स्थानीय कतार) को जोड़ने से समस्या ठीक नहीं होगी, क्योंकि यह ज्यादातर तब होता है जब विभिन्न प्रक्रियाएं एक ही फ़ाइल को लिखने (नाम बदलने) का प्रयास करती हैं।

एक बार और सभी के लिए समसामयिक मुद्दों को ठीक करने के लिए, हमें पुनर्विचार करना पड़ सकता है कि हम कैशिंग कैसे करते हैं, उदाहरण के लिए कैश को एक्सेस करने वाली एक एकल प्रक्रिया है, जिसके साथ हम किसी प्रकार के आईपीसी पर संवाद करते हैं। मौजूदा की / वैल्यू स्टोर सिस्टम आसान हो सकते हैं, जैसे memcached ।

मुझे लगता है कि इस तर्क (स्थानीय कतार) को जोड़ने से समस्या ठीक नहीं होगी, क्योंकि यह ज्यादातर तब होता है जब विभिन्न प्रक्रियाएं एक ही फ़ाइल को लिखने (नाम बदलने) का प्रयास करती हैं।

आह, मैं शायद इस मुद्दे को गलत समझा। जिस तरह से मैंने इसे पढ़ा है, पुस्तकालय में पहले से ही एक कतारबद्ध तंत्र है जो async अनुरोधों के लिए अच्छी तरह से काम करता है, लेकिन यदि आप सिंक अनुरोधों में मिश्रण करते हैं तो _ अच्छी तरह से आप टकराव प्राप्त कर सकते हैं।

मेरे ऊपर संदर्भित पुल अनुरोध को इस मुद्दे को हल करना चाहिए। कम से कम यह मेरे लिए किया था!

@mekwall, मुझे लगता है कि वे उपयोग कर रहे rename() में की async संस्करण writeFile() , और यह अभी भी अपने परीक्षण में विफल रहता है: https://github.com/asapach/write-atomic-issue। क्या आप कृपया मेरे रेप्रो को चलाने की कोशिश कर सकते हैं? मुझे लगता है कि आपका परिवर्तन इस समस्या की संभावना को कम कर सकता है, लेकिन इसे पूरी तरह से समाप्त नहीं करता है।

@asapach क्या आपने मेरे परिवर्तनों के साथ प्रयास किया? क्योंकि मैंने कई बार कोशिश की, और मुझे हर बार बिना मिले हुए अपने बदलावों के साथ EPERM: operation not permitted, rename मिला।

@mekwall , yep, अभी भी आपके परिवर्तनों (हालांकि async-ly) के साथ विफल हो रहा है। (नीचे ठीक किया गया है।)

या बल्कि तकनीकी रूप से यह विफल नहीं होता है (क्योंकि सिंक प्रवाह बाधित नहीं होता है), लेकिन कंसोल अभी भी EPERM त्रुटियों से अटे पड़े हैं।

@asapach मुझे वह समस्या मिली जो आप कर रहे हैं। यह graceful-fs पॉलीफिल में है। मैंने इस PR में एक फिक्स पोस्ट किया है: https://github.com/isaacs/node-graceful-fs/pull/119

@mekwall , हाँ इस मुद्दे को संबोधित करने के लिए लगता है - दोनों सिंक और async संस्करणों में कोई और त्रुटि नहीं है।
अब समस्या यह है कि अस्थायी फ़ाइलों को हटाया नहीं जाता है, क्योंकि fs.unlinkSync(tmpfile) कभी नहीं कहा जाता है: https://github.com/npm/write-file-atomic/pull/29/files#diff -168726d96b3ce427e7fedce31bb0bcR198

@asapach मैंने graceful-fs नाम बदलने के लिए अनलिंक जोड़ दिया, लेकिन मुझे यकीन नहीं है कि अगर यह जाने का सही तरीका है। Afaik fs.rename MoveFile फ़ंक्शन का उपयोग करता है और उसे स्रोत को गंतव्य पर कॉपी नहीं करना चाहिए। स्रोत को केवल नाम बदलना चाहिए और स्रोत और गंतव्य एक ही समय में कभी भी मौजूद नहीं होना चाहिए।

@ मीकावल , जो थोड़ी मदद करता है, लेकिन कुछ मामलों में अगर कार्यकर्ता को जल्दी समाप्त कर दिया जाता है (क्योंकि सभी काम पूरा हो गया है), कुछ फ़ाइलों को साफ नहीं किया जाता है, क्योंकि यह सफाई का इंतजार नहीं करता है। Async संस्करण ठीक काम करता है।

@ समापक यह उम्मीद के

@ आसपैक मुझे एहसास हुआ कि मेरे पीआर write-file-atomic लिए काम नहीं करेंगे, इसलिए मैंने fs.renameSync graceful-fs को एक ही वर्कअराउंड के साथ fs.rename जोड़कर एक और दृष्टिकोण लिया। लेकिन अवरुद्ध। यह आपके टेस्ट वर्क को उम्मीद के मुताबिक ही बनाता है!

@mekwall , धन्यवाद, मैंने अपने
मुझे लगता है कि नीचे की ओर मुझे सिंक के लिए सीपीयू और डिस्क का उपयोग बढ़ा हुआ दिखाई दे रहा है, लेकिन यह शायद अपेक्षित है।

इसे चुनने और इसे ठीक करने में मदद करने के लिए बहुत से लोगों को धन्यवाद। बहुत सराहना की! ❤️ उम्मीद है कि सुशोभित-एफएस में सुधार सही है, और यह जारी हो जाता है।

@SimenB आपका स्वागत है! हम काम पर इस बात से दुखी हैं इसलिए मुझे अपनी टीम द्वारा इसकी जांच करने के लिए कुछ समय मिला। परिवर्तन बहुत सारे पैकेजों को प्रभावित करेंगे, इसलिए उन्हें इसे स्वीकार करने में सबसे अधिक समय लगेगा: /

किसी भी विचार जब यह वर्कअराउंड एक रिलीज के लिए कर देगा?

@cpojer क्या आप कुछ और जानकारी प्रदान कर सकते हैं कि यह बंद क्यों है? क्या कोई फ़िक्स प्रदान किया गया है? हमारे पास अभी भी यह मुद्दा है

क्षमायाचना, लगता है कि अभी तक सुशोभित- fs में उतरा नहीं है :(

क्या कई लोग इस बात की पुष्टि कर सकते हैं कि https://github.com/isaacs/node-graceful-fs/pull/119 का उपयोग करके उनके मुद्दों को हल किया जा सकता है?

आप यार्न रिज़ॉल्यूशन का उपयोग करके कांटा का उपयोग कर सकते हैं, https://yarnpkg.com/en/docs/selective-version-resolutions देखें , जो आपको सीआई आदि को फिक्स तैनात करने की अनुमति देनी चाहिए।

जैसे

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

@SimenB यह मेरे लिए समस्या को हल करता है, कम से कम It

+1 मेरे लिए भी।

@SimenB ने भी मेरा मुद्दा ठीक कर दिया है और मैं अब विंडोज़ पर jest 22 का उपयोग करने में सक्षम हूं। (हम इससे पहले 20 पर अटक गए थे)।

संपादित करें: वास्तव में, इसने मेरे देव लैपटॉप पर काम किया, लेकिन बिल्ड सर्वर पर काम नहीं किया। यह यार्न 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 पर्याप्त होना चाहिए, हालांकि एक कोशिश उन्नयन के लायक है

बस संकल्प करने की कोशिश की, लेकिन यह अभी भी मेरे लिए विफल है। हालाँकि मेरे पास दोनों और 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 को लक्षित करेंगे, लेकिन यह लिनक्स-आधारित OS पर नहीं होना चाहिए।

@mekwall हाँ, विंडोज़ - लेकिन यह विंडोज़ सर्वर 2012 R2 है

यह मेरे लिए एक प्रमुख मुद्दा है और नवंबर 2016 से graceful-fs साथ कुछ भी नहीं हुआ है जो मैं देख सकता हूं। इसलिए मैं काफी निराशावादी हो रहा हूं कि प्रदान की गई @mekwall को जल्द ही किसी भी समय विलय नहीं किया जाएगा। क्या कोई अस्थायी समाधान है जिसका उपयोग हम -i ध्वज और रिज़ॉल्यूशन वर्कअराउंड के अलावा कर सकते हैं?

क्या --runInBand आपके लिए काम नहीं करता @frenic?

यह -i और हां, यह काम करता है। लेकिन दुर्भाग्य से यह बड़ी परियोजनाओं के लिए लंबे समय में टिकाऊ नहीं है।

मुझे लगता है कि हम अपना खुद का कांटा और प्रकाशित कर सकते हैं, लेकिन यह हर किसी के लिए ठीक काम नहीं लगता है

मैं एक ही स्थिति के साथ हूं, लेकिन मेरे मामले में, --runInBand काम नहीं करता है।

मैंने Jest के नवीनतम संस्करण के साथ graceful-fs ओवरराइड की जाँच की है और दुर्भाग्य से यह अब मज़बूती से काम नहीं कर रहा है क्योंकि मैंने अंतिम बार इसका परीक्षण किया था। अभी भी गैर-शून्य मौका है कि यह बड़े परीक्षण सूट पर एक दौड़ की स्थिति में चलता है।

इस धागे से स्क्रॉल करने के बाद, मुझे yarn का उपयोग करते हुए एक रिज़ॉल्यूशन मिला। क्या इसके बजाय npm का उपयोग करने का कोई संकल्प है?

हमारे पास अभी तक बहुत अच्छा भाग्य है जो हमारे पैकेज में graceful-fs का पैच संस्करण जोड़ रहा है। हमारे लिए npm और यार्न के साथ काम करता है।

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

नमस्ते,

किसी कारण से हम यह त्रुटि केवल जेनकींस से चलाते हैं, न कि स्थानीय रूप से चलाने पर (समान मशीन / फ़ोल्डर आदि पर भी)
@jsheetzati का समाधान हमारे लिए भी काम कर रहा है (

धन्यवाद,
मोर

जेनकिन्स से जेस्ट चलाने पर हमारे पास यह मुद्दा भी है। --runInBand विकल्प एकल नौकरी के निष्पादन के दौरान विफलता से बचने में मदद करता है लेकिन समानांतर में कई बिल्ड चलने पर भी जेस्ट विफल रहता है।
वर्कअराउंड के रूप में हम लॉक करने योग्य संसाधन प्लगइन का उपयोग यह सुनिश्चित करने के लिए करते हैं कि केवल jest प्रक्रिया को --runInBand विकल्प रखते हुए उसी समय निष्पादित किया जाए।
आशा है कि यह टिप्पणी किसी के लिए उपयोगी होगी।

@nyrkovalex हम आपके द्वारा जेस्ट के कैश डायरेक्टरी विकल्प का उपयोग करते हैं, यह सुनिश्चित करने के लिए कि कैश को कार्यक्षेत्रों में साझा नहीं किया गया है।

हम ऐसा जेस्ट प्रीसेट प्रकाशित करके करते हैं जो cacheDirectory: '<rootDir>/.jest-cache' सेट करता है और यह सुनिश्चित करता है कि सभी पैकेज इसका उपयोग करें। यदि ऐसा हो तो .jest-cache से .gitignore जोड़ना सुनिश्चित करें।

उस विकल्प को जोड़ने से पहले हम 16 निष्पादनकर्ता प्रति जेनकिंस एजेंट में वैश्विक जेस्ट कैश साझा करने के परिणामस्वरूप कई मुद्दों पर चलेंगे। लॉक करने योग्य संसाधनों का उपयोग

@ aescobar1991 यह विकल्प निश्चित रूप से एक बेहतर समाधान है, हम इसका उपयोग करने पर विचार करेंगे।
एक टिप के लिए धन्यवाद!

नमस्ते,

हम npm को चलाने के लिए ग्रेडेल का उपयोग करते हैं (ऐसा क्यों न करें :)) और जेनकिंस के साथ संयोजन एक हत्यारा है।
हमने कोशिश की:

1. कैश को वैश्विक कैश के बजाय स्थानीय निर्देशिका पर सेट करना
2. का उपयोग कर --runInBand
3. एजेंट पर केवल एक ही काम चल रहा है- कोई समानांतर नौकरी नहीं
4. रनिंग टेस्ट -मैक्स-वर्कर 1 (और उपयोग नहीं - समानांतर)

सभी एक ही त्रुटि के साथ विफल हो जाते हैं।
एकमात्र समाधान जो हमारे लिए काम करता है वह @jsheetzati द्वारा एक है - काश यह औपचारिक रूप से तय हो जाता।

हम शायद उस फिक्स को कांटे और प्रकाशित कर सकते थे

वह तो जबर्दस्त होगा...

मुझे यह समस्या बहुत है और सुशोभित एफएस के लिए पैच ने मेरे लिए काम किया। इसलिए मैं इस सुधार की सराहना करूंगा।

सुशोभित-एफएस के साथ काम करने के लिए एक समाधान के रूप में, क्या आप बस प्रत्येक श्रमिक प्रक्रिया / धागा नहीं दे सकते हैं यह दौड़ की स्थिति से बचने के लिए कैश डायरेक्टरी है?

यह शायद धीमा है, लेकिन हमें अपने CI सर्वर पर --runInBand का उपयोग करना होगा और यह अधिक खराब है।

अगर कोई मुझे देखने के लिए सही फ़ाइलों पर इंगित कर सकता है, तो मैं एक पैच लिखने की कोशिश भी कर सकता हूं। मेरे पास वास्तव में कठिन समय है जो जस्ट के स्रोत को नेविगेट कर रहा है।

मुझे यकीन नहीं है कि यह क्या है, लेकिन कुछ महीनों से संभवतः कुछ सप्ताह हो गए हैं और मैंने अब तक विफलता नहीं देखी है। हम थोड़ी देर के लिए २२.४.२ का उपयोग कर रहे हैं और हाल ही में २२.४.४ में अपग्रेड किया गया है। हमने कई अन्य पैकेज भी अपडेट किए हैं।

बस में चिप करने के लिए - मैं एक विंडो Jenkins CI सर्वर पर jest 23.6 के साथ यह देख रहा हूं।

• --runInBand काम करता है, लेकिन परीक्षण के समय को दोगुना कर देता है, इसलिए यह महान नहीं है, और चूंकि हमारे पास परीक्षण पुश से पहले चलते हैं, इसलिए मैं अपनी टीम के सदस्यों को सुपर-उदास किए बिना इसे सक्षम नहीं कर सकता
• @jsheetzati (https://github.com/facebook/jest/issues/4444#issuecomment-370533355) द्वारा बताए अनुसार package.json में ग्रेसफुल -एफएस ओवरराइड करता है, लेकिन यह एक हैक का एक सा है।

चूँकि 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 के साथ रनिंग जेस्ट पहली बार समस्या को हल नहीं करता है, लेकिन केवल एक और रन के बाद यह त्रुटियों के बिना निष्पादित होता है।

TFS बिल्ड के भाग के रूप में विंडोज 10 एंटरप्राइज VM पर चल रहा है।

@EthhanSankin क्या आप लिंक किए गए

मैं graceful-fs लिए एक प्रतिस्थापन पर काम कर रहा हूं जो इन मुद्दों को हल करना चाहिए। यह वर्तमान में अल्फा में है, लेकिन कुछ शुरुआती अपनाने वालों के लिए यह बहुत अच्छा होगा: https://github.com/mekwall/normalized-fs

राइट-फाइल-एटॉमिक के पुराने संस्करण पर लौटने से समस्या हल हो गई।

@moizgh किस संस्करण से किस संस्करण तक?

@moizgh किस संस्करण से किस संस्करण तक?

२.४.२ से २.३.०

@iarna लगता है जैसे सोम प्रतिगमन शुरू किया गया था।

इस मुद्दे में भी चल रहा है, किसी भी बेहतर / स्थायी फिक्स में अंतर्दृष्टि?

यह पिछले कुछ महीनों में हमारे लिए फिर से शुरू हुआ - विंडोज़ - बहुत रुक-रुक कर।

लिखने-फ़ाइल-परमाणु अब सुशोभित- fs का उपयोग नहीं करता है - शायद इसके साथ कुछ करना है?