Пример gitlab-ci.yaml с запуском тестов


В материале приведем пример файла .gitlab-ci.yaml с запуском тестов. Статья является продолжением вводного материала про Gitlab-ci



Создаем файл .gitlab-ci.yml со сценарием сборки и запуска приложения

mcedit .gitlab-ci.yml

image: ubuntu:latest
variables:
  TEST_NAME: registry.gitlab.com/smth/gitlab-cicd.git:CI_REF_NAME
stages:
  - build
  - run

build_docker_image:
  stage: build
  script:
    - docker login -u USER -p $runnerPass registry.gitlab.com
    - docker build -t $TEST_NAME
    - docker push $TEST_NAME
  tags:
  - build
    
    
run:
  stage: run
  script:
    - docker login -u USER -p $runnerPass registry.gitlab.com
    - docker pull -t $TEST_NAME
    - docker kill $(docker ps -q) || true
    - docker rm $(docker ps -a -q) || true
    - docker run -dt -p 8080:80 --name gitlabCICDContainer $TEST_NAME
  tags:
  - run


Runner-ы с указанными тэгами должны быть зарегистрированы до запуска pipeline. До выполнения git push, который вызовет сценарий CI/CD.



В интерфейсе Gitlab нужно нажать check piplines для проверки синтаксиса.

Сами тесты и сборка автоматически запускаются после отправки кода в репозиторий, после выполнения git push.



Разработчик добавляет удаленный репозиторий по его домену или ip адресу.

git add remote origin https://repo.example.com/git

Добавляет файлы в staging, делает коммиты и потому отправляет код на удаленный сервер запуская сценарии заданные в gitlab-ci.yml

git push origin base_app



Полный пример .gitlab-ci.yml для приложения


image: ubuntu:latest
variables:
  WORK_DIR: ${CI_PROJECT_NAME}
  BRANCH: ${CI_COMMIT_REF_NAME}
  REPO: https://gitlab.com/smth/gitlab-cicd.git
stages:
  - test
  - deploy

test:
  stage: test
  environment: 
    name: Test
    url: "$TST_URL"
  before_script:
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  - mkdir -p ~/.ssh
  - eval $(ssh-agent -s)
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
  script:
    - ssh-add <(echo "$PRIVATE_KEY")
    - rm -rf .git
    - ssh -o StrictHostKeyChecking=no ubuntu@"$TST_SERVER" "rm -rf ~/${WORK_DIR}; mkdir ~/${WORK_DIR}; git init; git clone -b ${BRANCH} ${REPO}; cd ${WORK_DIR}; npm install; npm install forever -g; npm run stop; npm run ci"
  only:
    - branches
  except:
    - master
    
    
deploy:
  stage: deploy
  environment: 
    name: Production
    url: "$PRD_URL"
  before_script:
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  - mkdir -p ~/.ssh
  - eval $(ssh-agent -s)
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
  script:
    - ssh-add <(echo "$PRIVATE_KEY")
    - rm -rf .git
    - ssh -o StrictHostKeyChecking=no ubuntu@"$PRD_SERVER" "rm -rf ~/${WORK_DIR}; mkdir ~/${WORK_DIR}; git init; git clone -b ${BRANCH} ${REPO}; cd ${WORK_DIR}; npm install; npm install forever -g; npm run stop; npm run start-background"
  only:
    - master

Здесь видно, при вызове сценария будут выполняться действия, которые делятся на два этапа: test и deploy. Каждый из них привязывается к git ветке репрзитория.

В случае отправки изменеий в ветку master сценарий выполнит последовательность действий, предусмотренную этапом deploy. Приложение соберется и запустится на рабочем сервере.

В случае отправки изменеий в любую ветку кроме сценарий будет выполнять тесты. Тесты это все действия которые перечисляются после директивы script в сценарии.



Для двух веток могут быть разные действия, кроме того — самое важное — различаются сервера, на которых вносятся изменения. Это или рабочий сервер, с которого отдается контент клиентам, либо тестовый сервер или сервера — development стэнд, который используется для отладки.



Читайте про Gitlab Runner и регистрацию Docker Runner-ов.

Сказать спасибо