Verwenden Sie GitLab CI, um Tests lokal auszuführen?

Gibt es eine Möglichkeit, den Build lokal auszuführen, wenn ein GitLab-Projekt auf GitLab CI konfiguriert ist?

Ich möchte meinen Laptop nicht in einen Build "Runner" verwandeln, sondern nur Docker nutzen und .gitlab-ci.ymlTests lokal ausführen (dh alles ist vorkonfiguriert). Ein weiterer Vorteil davon ist, dass ich sicher bin, dass ich lokal und auf CI dieselbe Umgebung verwende.

Hier ist ein Beispiel für die lokale Ausführung von Travis-Builds mit Docker . Ich suche nach etwas Ähnlichem mit GitLab.

Seit einigen Monaten ist dies möglich mit gitlab-runner:

gitlab-runner exec docker my-job-name

Beachten Sie, dass Sie sowohl Docker als auch gitlab-runnerauf Ihrem Computer installiert benötigen , damit dies funktioniert.

Sie benötigen auch den imagein Ihrer .gitlab-ci.ymlDatei definierten Schlüssel . Sonst funktioniert es nicht.

Hier ist die Zeile, die ich derzeit zum lokalen Testen verwende gitlab-runner:

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

Hinweis: Sie können das Hinzufügen eines --docker-volumesmit Ihrer Schlüsseleinstellung standardmäßig in vermeiden /etc/gitlab-runner/config.toml. Weitere Informationen finden Sie in der offiziellen Dokumentation . Verwenden Sie gitlab-runner exec docker --helpdiese Option auch, um alle Docker-basierten Runner-Optionen anzuzeigen (z. B. Variablen, Volumes, Netzwerke usw.).

Aufgrund der Verwirrung in den Kommentaren gitlab-runner --helpfüge ich hier das Ergebnis ein, damit Sie sehen können, dass Gitlab-Runner Builds lokal erstellen kann:

   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 <[email protected]> 
   
COMMANDS:
   exec         execute a build locally
   [...]
   
GLOBAL OPTIONS:
   --debug          debug mode [$DEBUG]
   [...]

Wie Sie sehen können, execlautet der Befehl zu execute a build locally.

Obwohl es ein Problem gab, das aktuelle gitlab-runner execVerhalten zu verwerfen , wurde es erneut überdacht und eine neue Version mit größeren Funktionen ersetzt die aktuelle Exec-Funktionalität.

Beachten Sie, dass bei diesem Vorgang die Tests mithilfe Ihres eigenen Computers mithilfe von Docker-Containern ausgeführt werden. Hiermit werden keine benutzerdefinierten Läufer definiert. Gehen Sie dazu einfach zu den CI / CD-Einstellungen Ihres Repos und lesen Sie dort die Dokumentation. Wenn Sie sicherstellen möchten, dass Ihr Läufer anstelle eines von gitlab.com ausgeführt wird, fügen Sie Ihrem Läufer ein benutzerdefiniertes und eindeutiges Tag hinzu, stellen Sie sicher, dass nur markierte Jobs ausgeführt werden, und markieren Sie alle Jobs, für die Ihr Läufer verantwortlich sein soll.

Wenn Sie Gitlab mit dem Docker-Image dort ausführen: https://hub.docker.com/r/gitlab/gitlab-ce , können Sie Pipelines ausführen, indem Sie das lokale docker.sockmit einer Volume-Option verfügbar machen : -v /var/run/docker.sock:/var/run/docker.sock. Durch Hinzufügen dieser Option zum Gitlab-Container können Ihre Mitarbeiter auf die Docker-Instanz auf dem Host zugreifen.

Ich arbeite derzeit daran, einen Gitlab-Läufer zu entwickeln, der lokal funktioniert. Noch in den frühen Phasen, aber irgendwann wird es sehr relevant. Es scheint nicht so, als ob Gitlab Zeit haben möchte / hat, dies zu tun, also los geht's. https://github.com/firecow/gitlab-runner-local

Ein anderer Ansatz besteht darin, ein lokales Build-Tool zu haben, das gleichzeitig auf Ihrem PC und Ihrem Server installiert ist. Grundsätzlich wird Ihre .gitlab-ci.yml Ihr bevorzugtes Build-Tool aufrufen.

Hier ein Beispiel .gitlab-ci.yml, das ich mit nuke.build verwende:

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/

Und in nuke.build habe ich 3 Ziele definiert, die wie die 3 Stufen benannt sind (Build, Test, Pack).

Auf diese Weise haben Sie ein reproduzierbares Setup (alle anderen Dinge werden mit Ihrem Build-Tool konfiguriert) und können die verschiedenen Ziele Ihres Build-Tools direkt testen.

(Ich kann. \ build.ps1 ,. \ build.ps1 Test und. \ build.ps1 Pack aufrufen, wenn ich möchte)

Der GitLab-Runner scheint unter Windows noch nicht zu funktionieren, und es gibt ein offenes Problem, um dieses Problem zu beheben .

In der Zwischenzeit verschiebe ich meinen Skriptcode in ein Bash-Skript, das ich problemlos einem lokal ausgeführten Docker-Container zuordnen und ausführen kann.

In diesem Fall möchte ich in meinem Job einen Docker-Container erstellen, also erstelle ich ein Skript 'build':

#!/bin/bash

docker build --pull -t myimage:myversion .

In meiner .gitlab-ci.yaml führe ich das Skript aus:

image: docker:latest

services:
- docker:dind

before_script:
- apk add bash

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

Um das Skript lokal mit Powershell auszuführen, kann ich das erforderliche Image starten und das Volume den Quelldateien zuordnen:

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

Bash installieren, falls nicht vorhanden:

docker exec $containerId apk add bash

Festlegen von Berechtigungen für das Bash-Skript:

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

Führen Sie das Skript aus:

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

Dann stoppen Sie den Container:

docker stop $containerId

Und zum Schluss den Behälter aufräumen:

docker container rm $containerId

Die Idee ist, Prüfbefehle außerhalb von zu halten .gitlab-ci.yml. Ich verwende Makefileso etwas wie make checkund ich .gitlab-ci.ymlführe dieselben makeBefehle aus, die ich lokal verwende, um verschiedene Dinge vor dem Festschreiben zu überprüfen.
Auf diese Weise haben Sie einen Platz mit allen / den meisten Ihrer Befehle ( Makefile) und .gitlab-ci.ymlnur CI-bezogene Inhalte.

Ich bin unter Windows und verwende VSCode mit WSL

Ich wollte meinen Arbeits-PC nicht als Läufer registrieren, sondern führe stattdessen meine Yaml-Stufen lokal aus, um sie zu testen, bevor ich sie hochlade

$ 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