CircleCI nie buforuje mojego globalnie zainstalowanego modułu węzła?

Question

Próbuję buforować narzędzie wiersza poleceń potrzebne do mojego procesu kompilacji. Narzędzie jest wykonane z NodeJS. Kompilacja się powiedzie, ale potrzebuję jej, aby działać szybciej.

Odpowiednie części moich circle.yml wyglądać następująco:

dependencies:  
    post: 
    - npm -g list 
    - if [ $(npm -g list | grep -c starrynight) -lt 1 ]; then npm install -g starrynight; else echo "StarryNight seems to be cached"; fi 

test: 
    override: 
    - npm -g list 
    - starrynight run-tests --framework nightwatch 

Drugi npm -g list pokazuje starrynight dostępne do użytku, ale pierwszy z nich pokazuje, że jest nie są buforowane.

echo $(npm prefix -g) 

. . . masz mnie . . .

/home/ubuntu/nvm/v0.10.33 

. . . więc zakładam, że CircleCI nie buforuje niczego zainstalowanego globalnie w nvm.

Nic Próbowałem dostaje mi wiadomość, „StarryNight wydaje się być buforowane”.

Jak mogę buforować starrynight?

Answer 1

Ok, wymyśliłem to. Dzięki Hirokuni Kim z CircleCI za skierowanie mnie we właściwym kierunku.

Odpowiednie fragmenty nowej circle.yml wygląda następująco:

machine: 
    node: 
    version: 0.10.33 

dependencies: 
    cache_directories: 
    - ~/nvm/v0.10.33/lib/node_modules/starrynight 
    - ~/nvm/v0.10.33/bin/starrynight 
    pre: 
    - if [ ! -e ~/nvm/v0.10.33/bin/starrynight ]; then npm install -g starrynight; else echo "Starrynight seems to be cached"; fi; 

Hirokuni zasugerował buforowanie ~/nvm ale odzyskiwanie pamięci podręcznej trwało tak długo, jak budować, ponieważ przywraca każdą dostępną wersję nodejs.

Próbowałem wcześniej buforować tylko ~/nvm/v0.10.33/lib/node_modules/starrynight na własną rękę, nie zdając sobie sprawy, że siostrzany "katalog" bin/starrynight jest w rzeczywistości istotnym dowiązaniem symbolicznym do punktu wejścia modułu.

Moje robocze założenie polega na tym, że moduły NodeJS są uruchamiane z wiersza poleceń przez serię symbolicznych odnośników, prawdopodobnie w następujący sposób. . .

npm install -g starrynight tworzy dwie nowe artefakty:

• aliasem środowisko dla npm nazwie starrynight
• dowiązaniem w katalogu ${prefix}/bin, co wskazuje na plik punkcie wejścia starrynight.js określonym z kluczem package.jsonbin.

Gdy użytkownik wprowadzi starrynight jak CLI polecenia powłoka interpretuje jako aliasu npm i wykonuje je. npm analizuje 0 USD, pobiera starrynight i uruchamia nodejs z dowiązaniem symbolicznym ${prefix}/bin/starrynight jako modułem do wykonania. To dowiązanie symboliczne odnosi się do ~/nvm/v0.10.33/lib/node_modules/starrynight, gdzie odbywa się prawdziwa akcja.

W skrócie, jest to konieczne do buforowania zarówno ${prefix}/lib/node_modules/xxx i ${prefix}/bin/xxx

Answer 2

ścieżka w akceptowanych odpowiedź nie wydaje się już pracować. Sprawdziłem na przykład budowy, który teraz globalne pakiety KMP są w

/opt/circleci/nodejs/<version> 

więc dodałem do circle.yml następujące:

- "/opt/circleci/nodejs/v4.3.2/lib/node_modules" 
- "/opt/circleci/nodejs/v4.3.2/bin"