web-dev-qa-db-fra.com

Configuration de Gitlab CI Runner avec cache sur le menu fixe

Je n'arrive pas à faire en sorte que la mémoire cache ou les artefacts soient transférés entre les tâches dans gitlab CI. Je soupçonne que cela a quelque chose à voir avec ma configuration, mais je ne sais pas quoi. J'utilise gitlab et gitlab-ci-multirunner, tous deux dans docker, en utilisant la configuration suivante de docker-compose. J'ai omis la configuration de la base de données et certaines variables d'environnement par souci de brièveté:

version: '2'

services:
  gitlab:
    image: sameersbn/gitlab:8.5.1
    links:
      - redis:redisio
      - postgresql:postgresql
    ports:
      - "10080:80"
      - "10022:22"
    environment:
      ...
    volumes:
      - gitlab_data:/home/git/data

  gitlab-ci-runner:
    restart: always
    image: gitlab/gitlab-runner
    volumes:
      - gitlab_runner_config_data:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/nginx/ssl/gitlab.crt:/etc/gitlab-runner/certs/ca.crt
      - /etc/ssh:/ssh
    links:
      - gitlab:gitlab

  redis:
    ...
  postgresql:
    ...


volumes:
  postgresql_data:
  redis_data:
  gitlab_data:
  gitlab_runner_config_data:

La configuration du coureur (config.toml) est la suivante:

concurrent = 1

[[runners]]
  name = "docker"
  url = <public gitlab url>/ci 
  token = <gitlab token>
  tls-ca-file = "/etc/gitlab-runner/certs/ca.crt"
  executor = "docker"
  [runners.docker]
    image = "docker-bash"
    volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]

L’image docker-bash à laquelle il est fait référence est simplement le menu fixe: 1.10 image avec bash installé.

Mon processus de construction comprend 3 étapes:

  1. Exécutez npm install et les tests dans le nœud officiel: 5 image. Pour l'instant, j'ai oublié cette étape afin de tester le déploiement.
  2. Construire une image de menu fixe contenant le code
  3. Utilisez ansible, via une image docker personnalisée construite pour être déployée sur le serveur de production.

Le fichier .gitlab-ci.yml ressemble à ceci:

variables:
  FULL_IMAGE_TAG: deploy-$CI_BUILD_REF_NAME:$CI_BUILD_ID-$CI_BUILD_REF
  IMAGE_FILE: deploy-$CI_BUILD_REF_NAME.tar.gz

cache:
  paths:
    - $IMAGE_FILE

build:
  stage: build
  script:
    - docker build -t $FULL_IMAGE_TAG .
    - docker save $FULL_IMAGE_TAG | gzip -cf - > $IMAGE_FILE
  artifacts:
    paths:
      - $IMAGE_FILE

deploy:
  stage: deploy
  image: ansible-ssh
  script:
    - ls
    - ansible-playbook -e image_file=$IMAGE_FILE -e branch=$CI_BUILD_REF_NAME -e full_image_name=$FULL_IMAGE_TAG deploy-playbook.yml
  only:
    - develop
    - master

Comme vous pouvez le constater, l'image du menu fixe compressé est référencée ici à la fois dans les sections cache et artefacts, mais n'est pas réellement disponible dans l'étape de déploiement, où ansible est censée la copier sur la machine distante. J'ai essayé d'inclure une commande ls afin de vérifier le contenu du dossier et le fichier n'est clairement pas là, mais il est définitivement construit et je peux le télécharger à partir de l'interface utilisateur de gitlab. Voici le journal du travail de déploiement:

gitlab-ci-multi-runner 1.0.4 (014aa8c)
Using Docker executor with image ansible-ssh ...
Pulling docker image ansible-ssh ...
WARNING: Cannot pull the latest version of image ansible-ssh : Error: image library/ansible-ssh not found
WARNING: Locally found image will be used instead.

Running on runner-59d43cf3-project-8-concurrent-0 via 381c2ea97744...
Fetching changes...
Removing artifacts.Zip
Removing deploy-develop.tar.gz
HEAD is now at 6009bd0 test
Checking out 6009bd0f as develop...
HEAD is now at 6009bd0... test

$ ls
Dockerfile
deploy-playbook.yml
server
$ ansible-playbook -e image_file=$IMAGE_FILE -e branch=$CI_BUILD_REF_NAME -e full_image_name=$FULL_IMAGE_TAG deploy-playbook.yml
Using /etc/ansible/ansible.cfg as config file
1 plays in deploy-playbook.yml

PLAY ***************************************************************************

TASK [setup] *******************************************************************
ok: [deploy-Host]

TASK [copy docker image] *******************************************************
task path: /builds/test/test/deploy-playbook.yml:44
fatal: [deploy-Host]: FAILED! => {"changed": false, "failed": true, "msg": "could not find src=/builds/test/test/deploy-develop.tar.gz"}

NO MORE HOSTS LEFT *************************************************************
    to retry, use: --limit @deploy-playbook.retry

PLAY RECAP *********************************************************************
deploy-Host            : ok=1    changed=0    unreachable=0    failed=1   


ERROR: Build failed with: exit code 1

Je suspecte de ne pas configurer ou utiliser correctement le coureur, mais je ne trouve pas grand chose dans la documentation pour des cas autres que des cas vraiment simples et je ne connais pas suffisamment l'outil pour savoir comment tout cela s'emboîte sous le capot. . 

9
aquavitae

La mise en cache n'est pas conçue pour transmettre des fichiers entre les étapes d'une génération.

De la doc

cache: Définit la liste des fichiers à mettre en cache entre les exécutions suivantes

Je pense que ce dont vous avez besoin est en fait en cours: WIP: Téléchargez les artefacts de construction des étapes précédentes et restaurez-les dans le contexte de la construction (Aperçu technologique)

5
Pascal

Avez-vous activé les artefacts dans votre gitlab.rb 

gitlab_Rails['artifacts_enabled'] = false

comme décrit dans la documentation Construire des artefacts ?

1
Diego Ferri

Tout d’abord, mettez à jour gitlab et son coureur, en particulier le coureur 1.0.4 était plutôt expérimental.

Deuxièmement, dans la définition du cache, vous devez ajouter une clé voir https://docs.gitlab.com/ce/ci/yaml/README.html#cache-key

cache:
  key: "$CI_BUILD_REF_NAME"
  paths:
  - ..

À partir de https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md#the-runners-section , vous devez modifier le config.toml et ajouter un répertoire de cache

cache_dir:

répertoire où les caches de construction seront stockés dans le contexte de l'exécuteur sélectionné (localement, Docker, SSH). Si le programme d’exécution de docker est utilisé, ce répertoire doit être inclus dans son paramètre de volumes.

1
Danny

La mise en cache est un peu étrange, mais essentiellement:

<dir path> sous cache sont disponibles entre les tâches de construction, tandis que les artefacts <dir path> vous permettront de les utiliser dans la même tâche.

Alors:

cache:
  untracked: true
  key: "$CI_BUILD_REF_NAME"
  paths:
    - cache-dir/

setup:
  stage: setup
  [snip]
  artifacts:
    paths:
     - cache-dir/ #notice that the path above is the same

Cela vous permettra de mettre en cache vos fichiers entre chaque travail de construction tout en vous permettant d'utiliser le même cache inside le même travail.

N'oubliez pas d'ajouter les fichiers nécessaires aux artefacts à chaque étape de la construction.

0
avluis