Jak mogę przekazać artefakty do innego etapu?


107

Chciałbym używać GitLab CI z plikiem .gitlab-ci.yml do uruchamiania różnych etapów z oddzielnymi skryptami. W pierwszym etapie powstaje narzędzie, którego należy użyć w późniejszym etapie do wykonania testów. Zadeklarowałem wygenerowane narzędzie jako artefakt.

Jak mogę teraz wykonać to narzędzie w pracy na późniejszym etapie? Jaka jest poprawna ścieżka i jakie pliki będą się wokół niej znajdować?

Na przykład pierwszy etap tworzy artefakty / bin / TestTool / TestTool.exe i ten katalog zawiera inne wymagane pliki (biblioteki DLL i inne). Mój plik .gitlab-ci.yml wygląda następująco:

releasebuild:
  script:
    - chcp 65001
    - build.cmd
  stage: build
  artifacts:
    paths:
      - artifacts/bin/TestTool/

systemtests:
  script:
    - chcp 65001
    - WHAT TO WRITE HERE?
  stage: test

Kompilacja i testy działają w systemie Windows, jeśli jest to istotne.

Odpowiedzi:


102

Użyj dependencies. Na tym etapie testowania konfiguracji pobierze nieśledzone pliki, które zostały utworzone na etapie kompilacji:

build:
  stage: build
  artifacts:
    untracked: true
  script:
    - ./Build.ps1

test:
  stage: test
  dependencies: 
    - build
  script:
    - ./Test.ps1

9
Wreszcie udało się! Kluczową kwestią jest to, że zależności powinny być używane wraz z artefaktami. Tylko artefakty, które zostały uwzględnione, byłyby dostępne do użytku w kolejnym etapie. Nie trzeba dodawać, że należy zachować ostrożność w kwestii przesyłanych treści. Powiedziałbym, że użyj expire_in. W przeciwnym razie stracilibyśmy dużo miejsca. Te artefakty są przesyłane do gitlab w pracy / etapie / kroku kompilacji i pobierane w ramach testu.
ravikanth

18
Czy naprawdę musisz używać zależności? Stany dokumentacji Gitlab Note that artifacts from all previous stages are passed by default.. Pytanie brzmi, kiedy należy używać zależności.

2
Dokumentacja wyjaśnia
chetbox

3
Artefakty @Josefa ze wszystkich poprzednich etapów są przekazywane domyślnie (nie z poprzednich zadań)
Vivek

1
@Josef, gdy nie potrzebujesz wszystkich artefaktów ze wszystkich poprzednich etapów do bieżącego zadania. Powiedzmy, że masz 10 GB plików binarnych wygenerowanych na etapie kompilacji, ale Twój ostatni etap po prostu wysyła kilka e-maili o udanej kompilacji - nie musisz pobierać wszystkich 10 GB do tego zadania
Ezh

50

Ponieważ artefakty ze wszystkich poprzednich etapów są przekazywane domyślnie, wystarczy zdefiniować etapy w odpowiedniej kolejności. Wypróbuj poniższy przykład, który może pomóc w zrozumieniu.

image: ubuntu:18.04

stages:
  - build_stage
  - test_stage
  - deploy_stage

build:
  stage: build_stage
  script:
    - echo "building..." >> ./build_result.txt
  artifacts:
    paths:
    - build_result.txt
    expire_in: 1 week

unit_test:
  stage: test_stage
  script:
    - ls
    - cat build_result.txt
    - cp build_result.txt unittest_result.txt
    - echo "unit testing..." >> ./unittest_result.txt
  artifacts:
    paths:
    - unittest_result.txt
    expire_in: 1 week

integration_test:
  stage: test_stage
  script:
    - ls
    - cat build_result.txt
    - cp build_result.txt integration_test_result.txt
    - echo "integration testing..." >> ./integration_test_result.txt
  artifacts:
    paths:
    - integration_test_result.txt
    expire_in: 1 week

deploy:
  stage: deploy_stage
  script:
    - ls
    - cat build_result.txt
    - cat unittest_result.txt
    - cat integration_test_result.txt

wprowadź opis obrazu tutaj

W przypadku przekazywania artefaktów między zadaniami na różnych etapach, możemy użyć zależności wraz z artefaktami, aby przekazać artefakty, zgodnie z opisem w dokumencie .

I jeszcze prostszy przykład:

image: ubuntu:18.04

build:
  stage: build
  script:
    - echo "building..." >> ./result.txt
  artifacts:
    paths:
    - result.txt
    expire_in: 1 week

unit_test:
  stage: test
  script:
    - ls
    - cat result.txt
    - echo "unit testing..." >> ./result.txt
  artifacts:
    paths:
    - result.txt
    expire_in: 1 week

deploy:
  stage: deploy
  script:
    - ls
    - cat result.txt

Bardzo jasne wyjaśnienie, dziękuję. Jeśli etap nazywa artefakt o tej samej nazwie, co artefakt z poprzedniego etapu, czy oryginalny artefakt zostanie nadpisany?
Michael Osofsky

1
@MichaelOsofsky Możesz nazwać artefakt tą samą nazwą, oryginalny artefakt nie zostanie nadpisany przez ten z następnego etapu o tej samej nazwie. Następny etap pobiera tylko artefakt z poprzedniego etapu, jest to jego kopia. W przykładzie nazywam je inaczej, głównie ze względu na testy jednostkowe, a integracja będzie wykonywana równolegle. Jeśli usuniemy zadanie testowania integracji .eg, wszystkie zadania będą wykonywane po kolei, wtedy możemy użyć tej samej nazwy dla wszystkich artefaktów bez żadnego zamieszania. FYI, uzupełniam odpowiedź o jeszcze jeden przykład.
Chuan

W twoim przykładzie widzę, że dołączasz plik result.txt. Jeśli zastąpisz result.txt w zadaniu unit_test, zakładam, że wdrożenie zadania nigdy nie będzie miało dostępu do zawartości result.txt z kompilacji zadania. Proszę tylko o upewnienie się, że nigdy nie spowoduję tego typu błędów w moich skryptach.
Michael Osofsky

1
Zgodnie z dziennikiem etap wdrażania pobierze zarówno result.txt z etapu kompilacji, jak i testowania, ale późniejszy nadpisze poprzedni.
Chuan

1
BTW, oryginalny artefakt nie jest dotykany i zawsze jest dostępny do pobrania z CI / CD -> Pipelines, a następnie kliknij przycisk rozwijany Artefacts po prawej stronie, znajdziesz wszystkie artefakty wszystkich etapów.
Chuan
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.