Админ сайта познакомится с девушкой из Екатеринбурга. Напиши о себе/оставь контакт через форму обратной связи, заинтересуешь - свяжусь с тобой.

Настройка gitlab-ci.yml

Рассуждения

Вот мы написали тесты, настроили контейнеризацию, проверили все на десять раз (абсолютно буквально) на локальной машине. Пришло время скормить все это ранеру CI. Что может пойти не так?

Основная проблема — софт и железо, на котором гоняются пайплайны — по сути черный ящик. Узнать неочевидные нюансы можно, по сути, только путем проб, ошибок и научного тыка. В общем, в ногу стреляет часто.

Данный набор настроек хорошо себя показал.

Внимание! Эти настройки касаются только Cypress и его тестов. Попытка перенести их куда-то еще грозит падением пайплайнов, метеоритов и т.д.

Теория

Здесь будут термины, присущие пайплайнам GitLab. Их стоит узнать прежде чем читать дальше. Самые важные — джоба, стейдж, артефакты. Стоит ознакомиться со структурой gitlab-ci.yml и более-менее разобраться как работает ранер при запуске джобы

  1. Так как мы пользуемся общими с разработчиками настройками, у них может быть много того, чего нам не нужно.
  2. Наши тесты должны запускаться в отдельном стейдже.
  3. Нужно отключить шаги, которые выполняются перед всеми скриптами и заменить их на свои.
  4. Нужно директивно сделать исполняемым файл wait-for.
  5. Нужно сохранять результаты тестов.
  6. Некоторые настройки могут быть уникальными для проекта. Они не будут показаны.

Практика

Для начала добавим отдельный стейдж:

stages:

— test

— test-cypress // Это наш стейдж

— deploy

Тут комментарии излишни. Но стоит заметить что название для нашего стейджа можем выбрать произвольное.

Общий вид настройки будет выглядеть так:

test-cypress: // Произвольное название джобы

stage: test-cypress

image: docker/compose

before_script:

— echo «Test begin»

script:

— chmod +x ./tests/wait-for

— docker-compose --file docker-compose.cypress.yml up --exit-code-from cypress --build cypress

only:

— merge_request

artifacts:

when: always

paths:

— tests/artifacts

expire_in: 3 day

Итак, что же это означает? С названием все понятно, а вот что значат остальные строчки:

stage: test-cypress — задаем на каком стейдже будет происходить эта джоба

image: docker/compose — определяем образ, который будет использовать ранер. Нам очень важен docker-compose

before_script:

— echo «Test begin» — у нас имелся глобальный before_script, который использовали разработчики. Нам он совершенно не нужен. Этой настройкой мы переопределили его на простое сообщение в консоль

script:

— chmod +x ./tests/wait-for

— docker-compose --file docker-compose.cypress.yml up --exit-code-from cypress --build cypress — собственно основной скрипт, который будет выполняться состоит из двух частей:

  1. Делаем файл wait-for исполняемым
  2. Выполняем команду запуска основных тестов

only:

— merge_request — наши тесты будут производиться только при мерж-реквестах. Любых, не только наших.

artifacts:

when: always

paths:

— tests/artifacts

expire_in: 3 day — так мы сохраняем результаты тестов. В paths записывается путь до папки на машине-хосте (не в контейнере), которая будет скопирована в артефакты. Храниться будут 3 дня.

Ни добавить, ни отнять, как говорится. Не так уж и сложно.

Связанные статьи

0
Нет комментариев. Ваш будет первым!