Wie zu vermeiden, Neuinstallation Abhängigkeiten für jeden Job in Gitlab CI

Question

Ich verwende Gitlab CI 8.0 mit gitlab-ci-multi-runner 0.6.0. Ich habe eine .gitlab-ci.yml Datei ähnlich der folgenden:

before_script: 
    - npm install 

server_tests: 
    script: mocha 

client_tests: 
    script: karma start karma.conf.js 

Dies funktioniert, aber es bedeutet, dass die Abhängigkeiten unabhängig vor jedem Test Job installiert sind. Bei einem großen Projekt mit vielen Abhängigkeiten ergibt sich ein erheblicher Aufwand.

In Jenkins würde ich einen Job verwenden, um Abhängigkeiten zu installieren, dann TAR sie und erstellen Sie ein Build-Artefakt, das dann in Downstream-Jobs kopiert wird. Würde etwas ähnliches mit Gitlab CI funktionieren? Gibt es einen empfohlenen Ansatz?

Answer 1

Ein besserer Ansatz in diesen Tagen ist die Verwendung von artifacts zu machen.

Im folgenden Beispiel ist das Verzeichnis node_modules/ sofort für den Job lint verfügbar, nachdem die Stufe build erfolgreich abgeschlossen wurde.

build: 
    stage: build 
    script: 
    - npm install -q 
    - npm run build 
    artifacts: 
    paths: 
     - node_modules/ 
    expire_in: 1 week 

lint: 
    stage: test 
    script: 
    - npm run lint 

Answer 2

Ich denke, es ist nicht empfehlenswert, weil alle Jobs der gleichen Stufe parallel ausgeführt werden könnten.

1. Zuerst werden alle Jobs von Build parallel ausgeführt.
2. Wenn alle Jobs des Build erfolgreich sind, werden die Testjobs parallel ausgeführt.
3. Wenn alle Jobs des Tests erfolgreich sind, werden die Deploy-Jobs parallel ausgeführt.
4. Wenn alle Jobs der Bereitstellung erfolgreich sind, wird die Festschreibung als Erfolg markiert.
5. Wenn einer der vorherigen Jobs fehlschlägt, wird die Festschreibung als fehlgeschlagen markiert und keine Jobs der nächsten Stufe ausgeführt.

Ich habe das hier lesen:

http://doc.gitlab.com/ci/yaml/README.html

Answer 3

aktualisieren: Ich empfehle jetzt artifacts mit einem kurzen expire_in verwenden. Dies ist cache überlegen, da es das Artefakt nur einmal pro Pipeline schreiben muss, während der Cache nach jedem Job aktualisiert wird. Der Cache ist auch pro Runner. Wenn Sie also Ihre Jobs parallel auf mehreren Läufern ausführen, ist nicht garantiert, dass sie gefüllt sind, im Gegensatz zu Artefakten, die zentral gespeichert werden.

---

Gitlab CI 8.2 fügt runner caching mit dem Sie Dateien wiederverwenden können zwischen aufbaut. Allerdings habe ich festgestellt, dass dies sehr langsam ist.

Statt mein eigenes Caching-System mit einem wenig Shell-Skripten implementiert Ich habe:

before_script: 
    # unique hash of required dependencies 
    - PACKAGE_HASH=($(md5sum package.json)) 
    # path to cache file 
    - DEPS_CACHE=/tmp/dependencies_${PACKAGE_HASH}.tar.gz 
    # Check if cache file exists and if not, create it 
    - if [ -f $DEPS_CACHE ]; 
    then 
     tar zxf $DEPS_CACHE; 
    else 
     npm install --quiet; 
     tar zcf - ./node_modules > $DEPS_CACHE; 
    fi 

Dies vor jedem Job in Ihrem .gitlab-ci.yml läuft und nur Ihre Abhängigkeiten installieren, wenn package.json oder die Cache-Datei geändert hat, ist fehlt (zB erster Lauf oder Datei wurde manuell gelöscht). Beachten Sie, dass wenn Sie mehrere Läufer auf verschiedenen Servern haben, diese jeweils ihre eigene Cache-Datei haben.

Sie können die Cache-Datei regelmäßig löschen, um die neuesten Abhängigkeiten zu erhalten. Wir tun dies mit folgendem cron-Eintrag:

@daily    find /tmp/dependencies_* -mtime +1 -type f -delete