Jest: 프로세스 간 캐시 쓰기 경쟁 조건

관련이 없나요? https://github.com/facebook/jest/pull/4432

나는 그렇게 믿지 않는다. 리포지토리에서 볼 수있는 경우는 2 개의 다른 프로세스 (병렬로 실행되는 동안)에 대해 동일한 파일이 조롱되어 한 프로세스에 파일이 잠겨 있기 때문에 캐시 쓰기 작업이 실패한다고 생각합니다. 그 티켓은 같은 내용을 가진 다른 파일에 관한 것 같습니다. 우리가 호스팅하는 리포지토리에이 문제가 발생한 사례가 없습니다.

우리는 기본적으로 테스트에서 동일한 문제에 직면합니다. 재현하는 한 가지 쉬운 방법은 jest cacheDirectory 를 제거하여 다음 실행시 캐시 생성을 강제하는 것입니다.
```테스트 스위트를 실행하지 못했습니다.

jest: failed to cache transform results in:

C : / myniceproject / src / jest-cache / jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b / 3f / settingsProvider_3f1439e55275a95ecfdb7dcb432f7958
실패 메시지 : EPERM : 작업이 허용되지 않음, 이름 바꾸기
'C : myniceprojectsrcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b3fsettingsProvider_3f1439e55275a95ecfdb7dcb432f7958.1630729137'
->
'C : myniceprojectsrcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b3fsettingsProvider_3f1439e55275a95ecfdb7dcb432f7958'`

동일한 문제가 발생하여 해결 방법을 찾을 수 없습니다. Jest는 기본적으로 이런 식으로 사용할 수 없습니다.

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
OS Windows

--no-cache 는 도움 jest-transform-cache 는 아직 작성 중입니다. 도움이되는 유일한 것은 --runInBand 이며, 이는 대규모 프로젝트에서는 거의 허용되지 않습니다.

문제 진단을 위해 할 수있는 일이 있습니까? 재현 사례를 만들어야합니까?

이 오류가 중요합니까? 전체 테스트 스위트를 삭제하지 않고 경고로 처리 할 수 ​​있습니까? 백 오프하고 재 시도하는 방법이 있습니까?

작은 재현이 있으면 좋을 것입니다.

여기 재현이 있습니다 : https://github.com/asapach/jest-cache-issue/
변환 캐시를 채우기 위해 babel-jest 까지 lodash-es 를 효과적으로 실행합니다.
이것은 두 개의 다른 컴퓨터 (Win8.1 및 Win10)에서 80 %의 시간 동안 실패합니다.
--no-cache 를 제거하면 100 % 실패합니다. --runInBand 추가하면 0 %로 낮아집니다.

(호기심으로 Win10의 WSL 에서 실행을 시도했지만 Posix API를 사용하여 문제를 재현 할 수 없음)

Windows에서만 발생합니까? 가상 머신 이외의 Windows 머신에 액세스 할 수 없으므로 디버깅하기 가장 쉬운 방법이 아닙니다.

@jeanlauliac # 4088에 write-file-atomic 을 (를) 추가했습니다. 도와 주시겠습니까?

이 문제는 https://github.com/npm/write-file-atomic/issues/10 및 https://github.com/npm/write-file-atomic/pull/22 와 매우 유사합니다

방금 procmon 추적을 실행했습니다. 다음은 문제의 예입니다.

시간 | 프로세스 이름 | PID | 운영 | 경로 | 결과 | 세부 묘사
-| -| -| -| -| -| -
16 : 54 : 43.2304011 | node.exe | 7624 | SetRenameInformationFile | ... constant_ee286bbcf367680ce61a90e506522f92.82986661 | 성공 | ReplaceIfExists : True, 파일 이름 : ... constant_ee286bbcf367680ce61a90e506522f92
16 : 54 : 43.2305499 | node.exe | 8208 | SetRenameInformationFile | ... constant_ee286bbcf367680ce61a90e506522f92.103872574 | 액세스 거부 | ReplaceIfExists : True, 파일 이름 : ... constant_ee286bbcf367680ce61a90e506522f92

보시다시피 두 프로세스가 서로 1ms 이내에 동일한 파일의 이름을 바꾸려고 시도하고 두 번째 프로세스는 실패합니다.

npm / write-file-atomic # 22가 writeFile() 의 비동기 버전을 해결한다고 생각하지만 writeFileSync() 는 여전히 영향을받습니다.

동일한 파일에 대해 worker-farm 에서 write-file-atomic 를 사용하는 것만으로도 실패를 보여주는 재현을 만들 수 있습니까? 그 프로젝트에 대한 문제를 해결하는 것이 좋을 것입니다.

또는 시작이 될 수있는 동일한 오류 (응용 자 CI가 있음)를 보여주는 jest 내에서 테스트를 작성할 수 있다면?

이 오류가 발생했을 때 우리가 원하는 동작이 무엇인지조차 모르겠습니다. 다시 쓰시겠습니까? 테스트를 다시 실행 하시겠습니까? 전체 테스트 파일?

좋아요. 다른 재현을 만들어 보겠습니다. 여러 프로세스를 생성하고 캐시를 비활성화 / 정리하고 실패 할 때까지 계속 실행해야하기 때문에 농담 테스트를 생성 할 수 있는지 확실하지 않습니다.

이 오류가 발생했을 때 우리가 원하는 동작이 무엇인지조차 모르겠습니다.

음, 우선 --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

지금까지 찾은 결과 : 동기화 버전이 예상대로 실패하지만 놀랍게도 비동기 버전도 실패합니다. 즉, 동일한 프로세스에서 실행되는 경우에만 재시도 대기열을 구현할 수 있으며 이는 우리의 경우에 도움이되지 않습니다.

나는 그것을 유지하고 싶다.

새 깃발? 매우 오해의 소지가있는 이름입니다. 그리고 예를 들어 CI에서는 어쨌든 캐시를 거의 원하지 않으므로 리소스가 낭비됩니다. 아니면 --no-cache 동안 단일 테스트 실행 내에서 생성 된 캐시가 사용되며 기존 캐시 만 무시합니까?

다음은 worker-farm 및 write-file-atomic 의 다른 재현입니다.

대박! write-file-atomic에 대한 문제를 열 ​​수 있습니까? 수정이 필요한 것 같고, 그렇지 않은 경우 (한 번에 여러 프로세스를 작성하는 것을 지원하지 않으려는 경우) 우리 쪽에서 다시 검토 할 수 있습니다. 어떻게 생각하십니까?

로컬에서 시도했지만 작동하는 것처럼 보였던 패치는 동일한 내용을 가진 파일로 이름을 바꾸려고 할 때 오류를 무시하는 것입니다. 다른 과정이 경주에서 '승리'한다는 의미 일 뿐이므로 무시하고 계속 진행할 수 있습니다.

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 API 수준에서 활성화 할 수있는 플래그가 없으면 Windows에서 원자 적 쓰기 / 이름 변경이 모두 불가능할 수 있습니다.

@jwbay 귀하의 솔루션이 나에게 합리적으로 보입니다! 👍 indexOf 대신 e.code === 'EPERM' (더 강력하고 특정 메시지에 의존하지 않음). 값을 확인하기 위해 파일을 다시 읽어야한다고 생각하지 않습니다. 이로 인해 추가 동시성 문제가 발생할 수 있기 때문입니다 (예 : 파일이 동시에 다른 프로세스에 의해 작성되는 경우). PR 좀 보내 주 시겠어요?

write-file-atomic 에 대한 PR 작업을 시작하려했습니다. "파일 동기화를 작성하라는 요청을 받았지만 이미 비동기로 작성되도록 대기열에있는 경우, 구제 조치를 취하십시오."(옵션이있을 수 있음) 동작을 켜려면). 하지만 Jest 수준에서이 문제를 처리 할 수 ​​있다면 서두르지 않을 것입니다. cc @jeanlauliac

필자는 "파일 동기화를 작성하라는 요청을 받았지만 비동기로 작성 될 대기열에 이미있는 경우"(아마도 다음 옵션을 사용할 수있는 경우)에 대한 PR 작업을 시작하려고했습니다. 동작을 켜십시오).

이 논리 (로컬 큐)를 추가해도 문제가 해결되지 않을 것이라고 생각합니다. 대부분 다른 프로세스가 동일한 파일에 쓰려고 할 때 (이름 바꾸기) 발생하기 때문입니다.

동시성 문제를 한 번에 해결하려면 캐싱을 수행하는 방법을 재고해야 할 수 있습니다. 예를 들어 캐시에 액세스하는 단일 프로세스가 있고 일종의 IPC를 통해 통신합니다. memcached 와 같은 기존 키 / 값 저장소 시스템이 유용 할 수 있습니다.

이 논리 (로컬 큐)를 추가해도 문제가 해결되지 않을 것이라고 생각합니다. 대부분 다른 프로세스가 동일한 파일에 쓰려고 할 때 (이름 바꾸기) 발생하기 때문입니다.

아, 아마 그 문제를 오해했을 것입니다. 내가 읽은 방식으로 라이브러리에는 이미 비동기 요청에 대해 잘 작동하는 대기열 메커니즘이 있지만 동기화 요청을 혼합하면 충돌이 발생할 수 있습니다.

위에서 언급 한 풀 요청이이 문제를 해결해야합니다. 적어도 그것은 나를 위해 그것을했다!

@mekwall, 나는 그들이 사용하는 생각 rename() 에서 의 비동기 버전 writeFile() , 그리고 여전히 내 테스트에 실패 https://github.com/asapach/write-atomic-issue. 내 재현을 실행 해 주시겠습니까? 귀하의 변경이이 문제가 발생할 가능성을 최소화 할 수 있다고 생각하지만 완전히 제거하지는 않습니다.

@asapach 내 변경 사항을 시도 했습니까? 여러 번 시도했지만 변경 사항 없이는 매번 가져 오는 동안 EPERM: operation not permitted, rename 를받지 못했습니다.

@mekwall , 그래, 여전히 변경 사항으로 인해 실패합니다 (비동기 적이지만). (아래에서 수정 됨)

또는 기술적으로는 실패하지 않지만 (동기화 흐름이 중단되지 않았기 때문에) 콘솔은 여전히 ​​EPERM 오류로 가득 차 있습니다.

@asapach 나는 당신이 가지고있는 문제를 발견했습니다. graceful-fs 폴리 필에 있습니다. 이 PR에 수정 사항을 게시했습니다 : https://github.com/isaacs/node-graceful-fs/pull/119

@mekwall , 예 이것은 문제를 해결하는 것 같습니다. 동기화 및 비동기 버전 모두에서 더 이상 오류가 없습니다.
이제 문제는 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 나는 깨달았다 내 PR을위한 write-file-atomic 하고자하지 작업, 나는 추가하여 다른 접근을했다, 그래서 fs.renameSync 에서 graceful-fs 와 같은 해결 방법으로 fs.rename 그러나 차단. 이렇게하면 테스트가 예상대로 작동합니다!

@mekwall , 감사합니다. 두 재현 사례 모두에서 변경 사항을 확인했지만 실패한 사례는 없습니다.
단점으로는 동기화를 위해 CPU 및 디스크 사용량이 증가한다고 생각하지만 아마도 예상 할 수 있습니다.

이 문제를 해결하고 해결하는 데 도움을 주신 많은 분들께 감사드립니다. 매우 감사! ❤️ graceful-fs의 수정이 올바른 수정이되어 출시되기를 바랍니다.

@SimenB 천만 에요! 우리는 직장에서 이로 인해 고통스러워서 우리 팀에서 이것을 조사 할 시간이 있습니다. 변경 사항은 많은 패키지에 영향을 미치므로 수락하는 데 시간이 걸릴 가능성이 큽니다.

이 해결 방법이 언제 출시 될지 알 수 있습니까?

@cpojer 폐쇄 이유에 대한 추가 정보를 제공 할 수 있습니까? 제공된 수정 사항이 있습니까? 여전히이 문제가 있습니다

죄송합니다. 수정 사항이 아직 graceful-fs에 포함되지 않은 것 같습니다.

여러 사람이 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 또한 내 문제를 해결했으며 이제 Windows에서

편집 : 사실, 그것은 내 dev 랩톱에서 작동했지만 빌드 서버에서는 작동하지 않았습니다. 그래도 yarn 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)

Yarn 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 빌드 서버에서 Windows를 실행합니까? graceful-fs 의 수정 사항은 Windows 만 대상으로하지만 Linux 기반 OS에서는 발생하지 않아야합니다.

@mekwall 예,

이것은 저에게 중요한 문제이며 2016 년 11 월 이후로 graceful-fs 대해 아무 일도 일어나지 않았습니다. 그래서 @mekwall이 제공 한 수정 사항이 곧 병합되지 않을 것이라는 비관적입니다. -i 플래그 및 해결 방법 외에 사용할 수있는 임시 솔루션이 있습니까?

--runInBand가 @frenic에서 작동하지 않습니까?

-i 와 동일하며 네, 작동합니다. 그러나 안타깝게도 대규모 프로젝트의 경우 장기적으로 지속 가능하지 않습니다.

포크하고 우리 자신의 것을 게시 할 수 있다고 생각하지만 수정이 모든 사람에게 효과가있는 것 같지는 않습니다.

저도 같은 상황이지만 제 경우에는 --runInBand가 작동하지 않습니다.

최신 버전의 Jest로 graceful-fs 재정의를 확인했는데 안타깝게도 마지막으로 테스트 한 이후로 더 이상 안정적으로 작동하지 않는 것 같습니다. 대규모 테스트 스위트에서 경쟁 조건이 발생할 가능성은 여전히 ​​0이 아닙니다.

이 스레드를 스크롤 한 후 yarn 사용하여 해결 방법을 찾았습니다. 대신 npm 를 사용하는 해결 방법이 있습니까?

지금까지 package.json에 graceful-fs 패치 버전을 추가하는 것만으로도 행운을 빕니다. npm과 실로 우리를 위해 일합니다.

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

안녕하세요,

어떤 이유로 로컬에서 실행할 때가 아니라 Jenkins에서 실행할 때만이 오류가 발생합니다 (동일한 컴퓨터 / 폴더 등에서도).
@jsheetzati 의 솔루션은 (npm 사용) 우리에게도 효과가 있지만 결국 패치입니다. 이 문제를 영구적으로 해결하기위한 ETA가 있습니까?

감사,
모르

Jenkins에서 jest를 실행할 때도이 문제가 발생합니다. --runInBand 옵션은 단일 작업 실행 중 실패를 방지하는 데 도움이되지만 여러 빌드를 병렬로 실행할 때 jest는 여전히 실패합니다.
해결 방법으로 잠금 가능한 리소스 플러그인 을 사용하여 --runInBand 옵션을 유지하면서 동시에 하나의 jest 프로세스 만 실행되도록합니다.
이 의견이 누군가에게 유용하기를 바랍니다.

@nyrkovalex 설명하는 문제를 피하기 위해 우리가하는 일은 Jest의 캐시 디렉토리 옵션 을 사용하여 캐시가 작업 공간에서 공유되지 않도록하는 것입니다.

cacheDirectory: '<rootDir>/.jest-cache' 를 설정하는 Jest 사전 설정을 게시하고 모든 패키지에서이를 사용하도록합니다. 이 경우 .jest-cache 을 .gitignore 합니다.

이 옵션을 추가하기 전에 Jenkins 에이전트 당 16 개의 실행기에서 전역 Jest 캐시를 공유하는 결과로 몇 가지 문제가 발생했습니다. 잠글 수있는 리소스 를 사용하면 언급 한대로 문제를 방지 할 수 있지만 Jenkins 에이전트를 잠재적으로 사용하지 않기 때문에 낭비입니다 (Jest 테스트가 병목 현상이 됨).

@ anescobar1991 이 옵션은 확실히 더 나은 솔루션이므로 사용을 고려할 것입니다.
팁 주셔서 감사합니다!

안녕하세요,

우리는 gradle을 사용하여 npm을 실행하고 (이유를 묻지 마십시오 :)) Jenkins와의 조합은 킬러입니다.
우리는 시도했습니다 :

1. 캐시를 전역 캐시 대신 로컬 디렉토리에 있도록 설정
2. --runInBand 사용
3. 에이전트에서 실행되는 단일 작업 만-병렬 작업 없음
4. gradle test --max-workers 1 실행 (--parallel을 사용하지 않음)

모두 동일한 오류로 실패합니다.
우리를 위해 작동하는 유일한 솔루션은 @jsheetzati 의 솔루션입니다. 공식적으로 수정되기를 바랍니다.

우리는 아마도 그 수정으로 포크하고 게시 할 수 있습니다.

그거 굉장 할거야 ...

나는이 문제를 많이 가지고 있으며 우아한 fs에 대한 패치가 나를 위해 일했습니다. 그래서 나는이 수정을 고맙게 생각합니다.

graceful-fs를 다루기위한 해결 방법으로 각 작업자 프로세스 / 스레드에 경합 상태를 피하기 위해 자체 캐시 디렉터리를 제공 할 수 없었습니까?

느릴 수도 있지만 CI 서버에서 --runInBand를 사용해야하며 이는 훨씬 더 나쁩니다.

누군가 나에게 올바른 파일을 알려줄 수 있다면 패치를 작성하려고 할 수도 있습니다. 농담의 원인을 탐색하는 데 정말 어려움을 겪습니다.

나는 그것이 무엇인지 확실하지 않지만 몇 주일 가능성이 두 달이 지났으며 더 이상 실패를 관찰하지 못했습니다. 우리는 한동안 jest 22.4.2를 사용하고 있으며 최근에는 22.4.4로 업그레이드했습니다. 다른 다양한 패키지도 업데이트했습니다.

그냥 칩 인-Windows Jenkins CI 서버에서 jest 23.6으로 이것을보고 있습니다.

• --runInBand 은 작동하지만 테스트 시간을 두 배로 늘려서 좋지 않습니다. 푸시 전에 테스트를 실행했기 때문에 팀원을 매우 슬프게 만들지 않고는 사용할 수 없습니다.
• @jsheetzati (https://github.com/facebook/jest/issues/4444#issuecomment-370533355)에서 언급했듯이 package.json 의 graceful-fs 재정의는 작동하지만 약간의 해킹입니다.

graceful-fs 는 이것에 대해 많은 일을하지 않기 때문에 (https://github.com/isaacs/node-graceful-fs/pull/131은 작년 7 월 이후로 행동을 보지 못했습니다), 아마도 포크 할 시간입니다. ? 나는 거기에 잔소리 주석을 추가했지만 누군가 갑자기 이것을 분류하기 위해 뛰어들 것으로 기대하지 않습니다.) ':

동일한 문제가 발생하지만 오류 메시지가 다릅니다.
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로 jest를 실행하면 처음에는 문제가 해결되지 않지만 다른 실행 후에 만 ​​오류없이 실행되는 것 같습니다.

TFS 빌드의 일부로 Windows 10 Enterprise VM에서 실행됩니다.

@EthanSankin 링크 된 graceful-fs PR

이 문제를 해결할 graceful-fs 의 대체품을 작업 중입니다. 현재 알파 버전이지만 얼리 어답터를 확보하면 좋을 것입니다 : https://github.com/mekwall/normalized-fs

이전 버전의 write-file-atomic으로 되 돌리면 문제가 해결되었습니다.

@moizgh 어떤 버전에서 어떤 버전으로?

@moizgh 어떤 버전에서 어떤 버전으로?

2.4.2에서 2.3.0

@iarna 는 som 회귀가 도입 된 것 같습니다.

또한이 문제에 직면하여 더 나은 / 영구적 인 수정에 대한 통찰력이 있습니까?

이것은 지난 몇 달 동안 우리에게 다시 시작되었습니다-창문-매우 간헐적이었습니다.

write-file-atomic은 더 이상 graceful-fs를 사용하지 않습니다. 아마도 그것과 관련이 있습니까?