2016-03-23 3 views
9

Я не могу заставить кеш или артефакты переноситься между заданиями в gitlab CI. Я подозреваю, что это связано с моей конфигурацией, но я не уверен, что. Я запускаю gitlab и gitlab-ci-multirunner, как в докере, используя следующую конфигурацию docker-compose. Я оставил из конфигурационных баз данных и некоторые из переменных окружения для краткости:Конфигурация бегуна Gitlab CI с кешем на докере

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: 

Конфигурация бегун (config.toml) является:

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"] 

docker-bash изображения упоминается только официальное docker:1.10 изображения с Баш установлен.

процесс Моя сборка состоит из 3 этапов:

  1. Run npm install и тесты в официальном node:5 изображения. На данный момент я оставил этот шаг, чтобы проверить развертывание.
  2. Постройте изображение докера, содержащее код
  3. Используйте доступный, с помощью встроенного скрытого образа докеры с помощью custome, чтобы развернуть построенное изображение на рабочий сервер.

.gitlab-ci.yml файл выглядит следующим образом:

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 

Как вы можете видеть, сжатый докер изображение упоминается здесь и в разделах кэша и артефакты, но на самом деле не доступны на этапе развертывания , где ansible должен скопировать его на удаленный компьютер. Я попытался включить команду ls, поэтому проверьте содержимое папки, и файл явно не существует, но он определенно построен, и я могу загрузить его из интерфейса gitlab. Вот лог с работы развертывания:

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 

Я подозреваю, что я не установки или с помощью бегунка правильно, но я не могу найти много документации, для чего за очень простые случаи, и я не» Знать инструмент достаточно хорошо, чтобы знать, как все это подходит под капотом.

+0

, чтобы быть уверенным, что шаги выполняются один за другим пытались ли вы добавить этапы: - строить - развернуть – Pascal

+0

я сделал, но я могу видеть, порядок их запуска в и это нормально. – aquavitae

+0

Что делать, если вы добавляете шаг 'артефакты' в задание' deploy'? Или переместите его ниже «cache», чтобы он повлиял на все задания? Другой вопрос: уверены ли вы, что «кеш» и «артефакты» могут указывать на один и тот же путь? Я не знаю, я просто пытаюсь помочь вам с логикой. ;) –

ответ

5

Кэширование не предназначено для передачи файлов между этапами сборки.

Из doc

кэша: Определить список файлов, которые должны храниться в кэше между последующими пробегов

Я думаю, что вам нужно, это на самом деле в процессе: WIP: Download build artifacts from previous stages and restore them in context of the build (Technology Preview)

+0

Да, это то, что я хочу, и это то, что я пытаюсь сделать, но не работает. Я прочитал обе эти ссылки и только добавил кеш, чтобы увидеть, будет ли это иметь значение. Несмотря на то, что говорится в документации, артефакты не восстанавливаются во второй работе. – aquavitae

+0

build: and deploy: не два задания, это всего лишь два шага одной и той же работы – Pascal

+0

Хорошо, может быть, семантика спорная, но что? Есть ли разница? – aquavitae

0

Прежде всего, обновление gitlab и gitlab runner, особенно 1.0.4 бегун был тихим экспериментальным.

Во-вторых, в определении кэша, необходимо добавить ключ см https://docs.gitlab.com/ce/ci/yaml/README.html#cache-key

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

С https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md#the-runners-section, вы должны изменить config.toml и добавить каталог с кэшем

cache_dir:

каталог где build caches будут храниться в контексте выбранного исполнителя (локально, Docker, SSH). Если используется исполнитель докеров, этот каталог должен быть включен в его параметр томов.

0

Кэширование немного странно, но, по существу:

<dir path> под кэш доступны между рабочими местами сборки, а <dir path> артефакты позволит использовать его в ту же самую работу.

Итак:

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 

Это позволит вам кэшировать файлы между каждой сборкой работой, позволяя вам использовать тот же кэш внутри ту же работу.

Не забудьте добавить файлы, необходимые для артефактов, на каждом этапе сборки.