Używać GitLab CI do lokalnego uruchamiania testów?

Jeśli projekt GitLab jest skonfigurowany w GitLab CI, czy istnieje sposób na lokalne uruchomienie kompilacji?

Nie chcę zmieniać swojego laptopa w „runner” kompilacji, chcę po prostu skorzystać z Dockera i .gitlab-ci.ymluruchamiać testy lokalnie (czyli wszystko jest wstępnie skonfigurowane). Kolejną zaletą jest to, że jestem pewien, że używam tego samego środowiska lokalnie i na CI.

Oto przykład, jak uruchamiać kompilacje Travisa lokalnie za pomocą Dockera , szukam czegoś podobnego z GitLab.

Od kilku miesięcy jest to możliwe dzięki gitlab-runner:

gitlab-runner exec docker my-job-name

Zauważ, że potrzebujesz zarówno dockera, jak i gitlab-runnerzainstalowanego na swoim komputerze, aby to działało.

Potrzebujesz również imageklucza zdefiniowanego w .gitlab-ci.ymlpliku. W przeciwnym razie nie zadziała.

Oto wiersz, którego obecnie używam do testowania lokalnego przy użyciu gitlab-runner:

gitlab-runner exec docker test --docker-volumes "/home/elboletaire/.ssh/id_rsa:/root/.ssh/id_rsa:ro"

Uwaga: Możesz uniknąć dodawania a --docker-volumesz kluczem, ustawiając go domyślnie w /etc/gitlab-runner/config.toml. Więcej informacji znajdziesz w oficjalnej dokumentacji . Służy również gitlab-runner exec docker --helpdo wyświetlania wszystkich opcji uruchamiania opartych na platformie Docker (takich jak zmienne, woluminy, sieci itp.).

Ze względu na zamieszanie w komentarzach gitlab-runner --helpwklejam tutaj wynik, abyś mógł zobaczyć, że gitlab-runner może tworzyć kompilacje lokalnie:

   gitlab-runner --help
NAME:
   gitlab-runner - a GitLab Runner

USAGE:
   gitlab-runner [global options] command [command options] [arguments...]
   
VERSION:
   1.1.0~beta.135.g24365ee (24365ee)
   
AUTHOR(S):
   Kamil Trzciński <ayufan@ayufan.eu> 
   
COMMANDS:
   exec         execute a build locally
   [...]
   
GLOBAL OPTIONS:
   --debug          debug mode [$DEBUG]
   [...]

Jak widać, execpolecenie to execute a build locally.

Mimo że wystąpił problem z wycofaniem obecnego gitlab-runner execzachowania , ostatecznie zostało ono ponownie rozważone i nowa wersja z większymi funkcjami zastąpi obecną funkcjonalność exec.

Zwróć uwagę, że ten proces polega na użyciu własnego komputera do uruchamiania testów przy użyciu kontenerów Dockera. Nie chodzi o definiowanie niestandardowych biegaczy. Aby to zrobić, po prostu przejdź do ustawień CI / CD repozytorium i przeczytaj tam dokumentację. Jeśli chcesz mieć pewność, że Twój biegacz jest wykonywany zamiast tego z gitlab.com, dodaj niestandardowy i unikalny tag do swojego elementu uruchamiającego, upewnij się, że uruchamia on tylko zadania oznaczone tagami i oznacz wszystkie zadania, za które chcesz, aby Twój biegacz był odpowiedzialny.

Jeśli używasz Gitlab używając obrazu Döcker tam: https://hub.docker.com/r/gitlab/gitlab-ce , możliwe do uruchomienia rurociągu poprzez wystawienie lokalna docker.sockz opcją objętości: -v /var/run/docker.sock:/var/run/docker.sock. Dodanie tej opcji do kontenera Gitlab umożliwi Twoim pracownikom dostęp do instancji dockera na hoście.

Obecnie pracuję nad stworzeniem gitlab runnera, który będzie działał lokalnie. Wciąż we wczesnych fazach, ale z czasem stanie się to bardzo istotne. Wygląda na to, że gitlab nie chce / ma czasu na zrobienie tego, więc proszę bardzo. https://github.com/firecow/gitlab-runner-local

Innym podejściem jest zainstalowanie lokalnego narzędzia do kompilacji na komputerze i serwerze w tym samym czasie. Więc w zasadzie twój .gitlab-ci.yml będzie w zasadzie wywoływał twoje preferowane narzędzie do budowania.

Oto przykład .gitlab-ci.yml, którego używam z nuke.build:

stages:
    - build
    - test
    - pack

variables:
    TERM: "xterm" # Use Unix ASCII color codes on Nuke

before_script:
    - CHCP 65001  # Set correct code page to avoid charset issues

.job_template: &job_definition
  except:
    - tags

build:
    <<: *job_definition
    stage: build
    script:
        - "./build.ps1"

test:
    <<: *job_definition
    stage: test
    script:
        - "./build.ps1 test"
    variables:
        GIT_CHECKOUT: "false"

pack:
    <<: *job_definition
    stage: pack
    script:
        - "./build.ps1 pack"
    variables:
        GIT_CHECKOUT: "false"
    only:
        - master
    artifacts:
        paths:
            - output/

W nuke.build zdefiniowałem 3 cele nazwane tak jak 3 etapy (budowanie, testowanie, pakowanie)

W ten sposób masz powtarzalną konfigurację (wszystkie inne rzeczy są konfigurowane za pomocą narzędzia do kompilacji) i możesz bezpośrednio testować różne cele narzędzia do kompilacji.

(Mogę zadzwonić do. \ build.ps1,. \ build.ps1 test i. \ build.ps1 pack, kiedy chcę)

Wydaje się, że runner GitLab jeszcze nie działa w systemie Windows i istnieje otwarty problem, aby rozwiązać ten problem .

W międzyczasie przenoszę więc kod mojego skryptu do skryptu bash, który mogę łatwo zmapować do kontenera docker działającego lokalnie i wykonać.

W tym przypadku chcę w mojej pracy zbudować kontener docker, więc tworzę skrypt 'build':

#!/bin/bash

docker build --pull -t myimage:myversion .

w moim .gitlab-ci.yaml wykonuję skrypt:

image: docker:latest

services:
- docker:dind

before_script:
- apk add bash

build:
stage: build
script:
- chmod 755 build
- build

Aby uruchomić skrypt lokalnie za pomocą PowerShell, mogę uruchomić wymagany obraz i zmapować wolumin z plikami źródłowymi:

$containerId = docker run --privileged -d -v ${PWD}:/src docker:dind

zainstaluj bash, jeśli nie jest obecny:

docker exec $containerId apk add bash

Ustaw uprawnienia do skryptu bash:

docker exec -it $containerId chmod 755 /src/build

Wykonaj skrypt:

docker exec -it --workdir /src $containerId bash -c 'build'

Następnie zatrzymaj pojemnik:

docker stop $containerId

I na koniec wyczyść pojemnik:

docker container rm $containerId

Chodzi o to, aby polecenia sprawdzania pozostawały poza .gitlab-ci.yml. Używam Makefiledo uruchamiania czegoś podobnego make checki .gitlab-ci.ymluruchamiam te same makepolecenia, których używam lokalnie, aby sprawdzić różne rzeczy przed zatwierdzeniem.
W ten sposób będziesz mieć jedno miejsce ze wszystkimi / większością swoich poleceń ( Makefile) i .gitlab-ci.ymlbędziesz mieć tylko rzeczy związane z CI.

Korzystam z systemu Windows i używam VSCode z WSL

Nie chciałem rejestrować swojego służbowego komputera jako biegacza, więc zamiast tego uruchamiam lokalnie moje etapy yaml, aby je przetestować, zanim je załaduję

$ sudo apt-get install gitlab-runner
$ gitlab-runner exec shell build

yaml

image: node:10.19.0 # https://hub.docker.com/_/node/
# image: node:latest

cache:
  # untracked: true
  key: project-name
  # key: ${CI_COMMIT_REF_SLUG} # per branch
  # key:
  #   files:
  #     - package-lock.json # only update cache when this file changes (not working) @jkr
  paths:
    - .npm/
    - node_modules
    - build

stages:
  - prepare # prepares builds, makes build needed for testing
  - test # uses test:build specifically @jkr
  - build
  - deploy

# before_install:

before_script:
  - npm ci --cache .npm --prefer-offline

prepare:
  stage: prepare
  needs: []
  script:
    - npm install

test:
  stage: test
  needs: [prepare]
  except:
    - schedules
  tags:
    - linux
  script:
    - npm run build:dev
    - npm run test:cicd-deps
    - npm run test:cicd # runs puppeteer tests @jkr
  artifacts:
    reports:
      junit: junit.xml
    paths:
      - coverage/

build-staging:
  stage: build
  needs: [prepare]
  only:
    - schedules
  before_script:
    - apt-get update && apt-get install -y zip
  script:
    - npm run build:stage
    - zip -r build.zip build
  # cache:
  #   paths:
  #     - build
  #   <<: *global_cache
  #   policy: push
  artifacts:
    paths:
      - build.zip

deploy-dev:
  stage: deploy
  needs: [build-staging]
  tags: [linux]
  only:
    - schedules
  #   # - branches@gitlab-org/gitlab
  before_script:
    - apt-get update && apt-get install -y lftp
  script:
    # temporarily using 'verify-certificate no'
    # for more on verify-certificate @jkr: https://www.versatilewebsolutions.com/blog/2014/04/lftp-ftps-and-certificate-verification.html
    # variables do not work with 'single quotes' unless they are "'surrounded by doubles'"
    - lftp -e "set ssl:verify-certificate no; open mediajackagency.com; user $LFTP_USERNAME $LFTP_PASSWORD; mirror --reverse --verbose build/ /var/www/domains/dev/clients/client/project/build/; bye"
  # environment:
  #   name: staging
  #   url: http://dev.mediajackagency.com/clients/client/build
  #   # url: https://stg2.client.co
  when: manual
  allow_failure: true

build-production:
  stage: build
  needs: [prepare]
  only:
    - schedules
  before_script:
    - apt-get update && apt-get install -y zip
  script:
    - npm run build
    - zip -r build.zip build
  # cache:
  #   paths:
  #     - build
  #   <<: *global_cache
  #   policy: push
  artifacts:
    paths:
      - build.zip

deploy-client:
  stage: deploy
  needs: [build-production]
  tags: [linux]
  only:
    - schedules
    # - master
  before_script:
    - apt-get update && apt-get install -y lftp
  script:
    - sh deploy-prod
  environment:
    name: production
    url: http://www.client.co
  when: manual
  allow_failure: true