eli 컴파일이 ci (원/트래비스)에서 매우 느립니다. 나는 개인적으로 다소 작은 느릅 나무 프로젝트를 위해 서클에서 30m가 넘는 빌드 시간을 겪고 있습니다. https://github.com/elm-lang/elm-compiler/issues/1473은 "CPU 개수 감지가 문제"라고 제안하고 실제 감지 된 금액 대신에 1 CPU를 반환하기 위해 libsysconfcpus을 사용하도록 권장합니다. 이 긴 컴파일 시간을 줄일 수있는 또 다른 방법이 있습니까?Circle CI 또는 Travis CI에서 Elm 컴파일 시간을 줄이는 방법은 무엇입니까?
사용자가 빠르고 더러운 수정을 원할 경우 : libsysconfcpus을 사용하여 sysconf에서 감지 된 CPU 양을 제한하면 실제로 원의 서클 크기가 elm-make 시간만큼 단축됩니다.
여전히 빌드 시간을 줄이기 위해 다른 방법을 찾고 있습니다. – sjt003
에서 https://elmlang.slack.com/archives/general/p1484149451013255
@rtfeldman :
가 CPU를 자신의 수를 잘못보고 때문에 원과 트래비스 모두 알려진 속도 문제가있다, 그러나 해결 방법이있다 : 이들의 해당하는 추가 당신의 원 구성 :
- https://github.com/elm-community/elm-test/blob/master/.travis.yml#L6
- https://github.com/elm-community/elm-test/blob/master/.travis.yml#L22-L30
- https://github.com/elm-community/elm-test/blob/master/.travis.yml#L39-L41 들은 기본적으로
elm-make가 가능한 CPU의 실제 수I 인식 될 정도로
sysconfcpus -n 2와elm-make를 실행하는 스크립트elm-make을 교환(편집) 서클 사람들과 조금 이야기를 나누었습니다. 그리고 tl; dr은 입니다. 그들은이 문제를 해결하는 데 관심이 없지만 그들이
이 설정을 고려 사용하고 일부 상류 물건의 미래 릴리스 : 당신의 .travis.yml에
sudo: true
. Haskell 빌드를 18 분에서 3 분으로 줄였습니다.
'libsysconfcpus'를 사용하는 것이 바람직한 해결책이 아닌 것 같습니다. – sjt003
시도하는 중이지만 해결 방법을 추천 한 것으로 받아 들일 수 없습니다. https://github.com/elm-lang/elm-compiler/issues/1473. 나는 ci에서 elm 빌드 시간을 줄이는 덜 해킹 된 방법을 찾고있다. – sjt003
'elm-stuff/build-artifacts' (제 1473 호에 언급 된 것 같습니다)를 캐싱 해 보셨습니까? 그것은 저에게 효과적이었습니다 (15 분에서 4 분 정도까지).하지만 캐시 될 종속성 단계에서 실행해야한다고 생각합니다. – jpvillaisaza