¿Usar GitLab CI para ejecutar pruebas localmente?

Si un proyecto de GitLab está configurado en GitLab CI, ¿hay alguna forma de ejecutar la compilación localmente?

No quiero convertir mi computadora portátil en un "corredor" de compilación, solo quiero aprovechar Docker y .gitlab-ci.yml ejecutar pruebas localmente (es decir, todo está preconfigurado). Otra ventaja de eso es que estoy seguro de que estoy usando el mismo entorno localmente y en CI.

Aquí hay un ejemplo de cómo ejecutar compilaciones de Travis localmente usando Docker , estoy buscando algo similar con GitLab.

Desde hace unos meses esto es posible usando gitlab-runner:

gitlab-runner exec docker my-job-name

Tenga en cuenta que necesita la ventana acoplable y la gitlab-runnerinstalación en su computadora para que esto funcione.

También necesita la imageclave definida en su .gitlab-ci.ymlarchivo. De lo contrario, no funcionará.

Aquí está la línea que utilizo actualmente para probar localmente usando gitlab-runner:

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

Nota: Puede evitar agregar un --docker-volumescon su clave configurándolo de forma predeterminada en /etc/gitlab-runner/config.toml. Consulte la documentación oficial para obtener más detalles . Además, use gitlab-runner exec docker --helppara ver todas las opciones de ejecución de Docker (como variables, volúmenes, redes, etc.).

Debido a la confusión en los comentarios, gitlab-runner --helppego aquí el resultado, para que pueda ver que gitlab-runner puede hacer compilaciones localmente:

   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]
   [...]

Como puede ver, el execcomando es execute a build locally.

Aunque hubo un problema para desaprobar el gitlab-runner execcomportamiento actual , terminó siendo reconsiderado y una nueva versión con mayores características reemplazará la funcionalidad ejecutiva actual.

Tenga en cuenta que este proceso consiste en utilizar su propia máquina para ejecutar las pruebas utilizando contenedores de Docker. Esto no es para definir corredores personalizados. Para hacerlo, simplemente vaya a la configuración de CI / CD de su repositorio y lea la documentación allí. Si desea asegurarse de que su corredor se ejecute en lugar de uno de gitlab.com, agregue una etiqueta personalizada y única a su corredor, asegúrese de que solo ejecute trabajos etiquetados y etiquete todos los trabajos de los que desea que su corredor sea responsable.

Si está ejecutando Gitlab utilizando la imagen ventana acoplable ahí: https://hub.docker.com/r/gitlab/gitlab-ce , es posible ejecutar las tuberías mediante la exposición del local, docker.sockcon una opción de volumen: -v /var/run/docker.sock:/var/run/docker.sock. Agregar esta opción al contenedor de Gitlab permitirá a sus trabajadores acceder a la instancia de Docker en el host.

Actualmente estoy trabajando en hacer un corredor de gitlab que funcione localmente. Aún en las primeras fases, pero eventualmente será muy relevante. No parece que gitlab quiera / tenga tiempo para hacer esto, así que aquí tienes. https://github.com/firecow/gitlab-runner-local

Otro enfoque es tener una herramienta de compilación local que esté instalada en su PC y en su servidor al mismo tiempo. Entonces, básicamente, su .gitlab-ci.yml básicamente llamará a su herramienta de compilación preferida.

Aquí un ejemplo .gitlab-ci.yml que uso con 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/

Y en nuke.build he definido 3 objetivos nombrados como las 3 etapas (construir, probar, empaquetar)

De esta manera, tiene una configuración reproducible (todas las demás cosas se configuran con su herramienta de compilación) y puede probar directamente los diferentes objetivos de su herramienta de compilación.

(Puedo llamar. \ build.ps1,. \ build.ps1 test y. \ build.ps1 pack cuando quiero)

El corredor de GitLab parece no funcionar todavía en Windows y hay un problema abierto para resolverlo .

Entonces, mientras tanto, estoy moviendo el código de mi script a un script bash, que puedo asignar fácilmente a un contenedor docker ejecuta localmente y ejecutar.

En este caso, quiero crear un contenedor de ventana acoplable en mi trabajo, así que creo un script 'build':

#!/bin/bash

docker build --pull -t myimage:myversion .

en mi .gitlab-ci.yaml ejecuto el script:

image: docker:latest

services:
- docker:dind

before_script:
- apk add bash

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

Para ejecutar el script localmente usando PowerShell, puedo iniciar la imagen requerida y mapear el volumen con los archivos fuente:

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

instalar bash si no está presente:

docker exec $containerId apk add bash

Establezca permisos en el script bash:

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

Ejecute el script:

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

Luego detenga el contenedor:

docker stop $containerId

Y finalmente limpia el recipiente:

docker container rm $containerId

La idea es mantener los comandos de verificación fuera de .gitlab-ci.yml. Utilizo Makefilepara ejecutar algo como make checky .gitlab-ci.ymlejecuta los mismos makecomandos que uso localmente para verificar varias cosas antes de confirmar.
De esta manera, tendrá un lugar con todos / la mayoría de sus comandos ( Makefile) y .gitlab-ci.ymlsolo tendrá cosas relacionadas con CI.

Estoy en Windows usando VSCode con WSL

No quería registrar mi PC de trabajo como corredor, así que en su lugar estoy ejecutando mis etapas de yaml localmente para probarlas antes de cargarlas.

$ 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