GitLab CI конфигурация

GitLab CI — это мощный инструмент для непрерывной интеграции, который позволяет автоматизировать процессы сборки, тестирования и деплоя. При настройке тестирования с использованием WebdriverIO в GitLab CI необходимо правильно настроить .gitlab-ci.yml файл, чтобы обеспечить корректный запуск тестов на разных этапах разработки.

1. Основы работы с GitLab CI

GitLab CI использует файл конфигурации .gitlab-ci.yml, в котором описаны все задачи (jobs), стадии (stages) и параметры для их выполнения. Конфигурация описывает, что должно происходить на каждом шаге, включая сборку проекта, выполнение тестов, деплой и другие процессы.

Каждая задача в файле конфигурации может быть настроена для выполнения в определённых окружениях и на определённых runners. GitLab предоставляет несколько возможностей для гибкой настройки CI/CD процессов, включая работу с Docker, использование кеширования, переменных окружения и многое другое.

2. Настройка базового `.gitlab-ci.yml` для WebdriverIO

Для начала необходимо создать файл .gitlab-ci.yml в корне репозитория, если его ещё нет. Вот пример простого конфигурационного файла, который запускает WebdriverIO тесты на каждом коммите.

stages:
  - install
  - test

install_dependencies:
  stage: install
  image: node:16
  script:
    - npm install

run_tests:
  stage: test
  image: node:16
  script:
    - npm run test
  artifacts:
    paths:
      - ./reports/
    expire_in: 1 week
  when: on_success

В этом примере:

stages: определяет два этапа — установку зависимостей и выполнение тестов.
install_dependencies: установка зависимостей проекта с использованием Docker-образа node:16.
run_tests: выполнение тестов с командой npm run test, где предполагается, что в package.json уже прописана команда для запуска тестов WebdriverIO.

3. Использование Docker для тестирования

Одним из самых удобных способов запуска тестов является использование Docker-образов. Docker предоставляет изолированное окружение, что позволяет избежать проблем с зависимостями и версиями операционных систем.

Для того чтобы использовать WebdriverIO в Docker, можно настроить файл таким образом, чтобы запуск тестов происходил в контейнере с браузером. Один из популярных способов — использование браузеров в контейнерах через Selenium или других подобных сервисов.

Пример конфигурации с использованием образа с Selenium:

stages:
  - install
  - test

install_dependencies:
  stage: install
  image: node:16
  script:
    - npm install

run_tests:
  stage: test
  image: selenium/standalone-chrome
  services:
    - selenium/standalone-chrome:latest
  script:
    - npm run test
  artifacts:
    paths:
      - ./reports/
    expire_in: 1 week
  when: on_success

Здесь в качестве Docker-образа для выполнения тестов используется selenium/standalone-chrome, что позволяет запустить браузер Chrome с поддержкой WebdriverIO.

4. Использование GitLab Runners

GitLab Runners — это агенты для выполнения CI/CD задач. Они могут быть настроены для работы на различных операционных системах, и их можно использовать как в облаке, так и локально.

При настройке CI для WebdriverIO необходимо учитывать, что GitLab предоставляет несколько типов runners, например, Shared Runners или специфичные для проекта Custom Runners. Если тесты должны быть запущены на специфичном сервере, необходимо настроить runner на этом сервере.

Пример конфигурации с использованием Custom Runner:

stages:
  - test

run_tests:
  stage: test
  script:
    - npm run test
  tags:
    - web-driver-test

В этом примере мы указываем тег web-driver-test для запуска задачи на Custom Runner, настроенном с этим тегом. Важно, чтобы runner был настроен и зарегистрирован с нужными параметрами.

5. Конфигурация для различных окружений

WebdriverIO тесты могут потребовать выполнения в различных окружениях, например, в разных браузерах или операционных системах. GitLab CI предоставляет возможность настройки различных условий для выполнения задач с использованием переменных окружения.

Пример конфигурации с поддержкой различных браузеров:

stages:
  - test

run_chrome_tests:
  stage: test
  script:
    - npm run test -- --browser chrome
  only:
    - master

run_firefox_tests:
  stage: test
  script:
    - npm run test -- --browser firefox
  only:
    - develop

В этом примере:

Задача для тестирования в браузере Chrome будет запускаться только на ветке master.
Задача для тестирования в браузере Firefox будет запускаться только на ветке develop.

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

6. Поддержка параллельных тестов

Если количество тестов в проекте велико, можно настроить параллельное выполнение тестов для ускорения процесса. WebdriverIO поддерживает параллельный запуск тестов, и GitLab CI позволяет разделить нагрузку между несколькими runners.

Пример конфигурации для параллельного выполнения тестов:

stages:
  - test

parallel_tests:
  stage: test
  script:
    - npm run test -- --parallel 4

В этом примере тесты будут выполняться параллельно в четыре потока. Это значительно ускоряет процесс тестирования, особенно при большом объеме тестов.

7. Отчёты и артефакты

Одним из важных аспектов в CI/CD процессе является сбор и хранение отчётов и артефактов. WebdriverIO может генерировать отчёты о тестах, и эти отчёты могут быть сохранены в GitLab CI для последующего анализа.

Пример конфигурации для сохранения отчётов:

stages:
  - test

run_tests:
  stage: test
  script:
    - npm run test
  artifacts:
    paths:
      - ./reports/*
    expire_in: 1 week

Здесь отчёты, созданные в процессе выполнения тестов, сохраняются в директорию ./reports/ и доступны в GitLab CI в течение недели.

8. Переменные окружения и секреты

GitLab позволяет использовать переменные окружения для настройки различных параметров. Это полезно для хранения конфиденциальных данных, таких как пароли, API-ключи и другие параметры, которые не должны быть закодированы в проекте.

Пример использования переменных окружения:

stages:
  - test

run_tests:
  stage: test
  script:
    - npm run test -- --user $CI_USER --password $CI_PASSWORD

Здесь переменные $CI_USER и $CI_PASSWORD могут быть заданы в настройках GitLab и используются в тестах, не раскрывая их в конфигурации.

9. Поддержка различных типов тестирования

GitLab CI также поддерживает запуск различных типов тестирования: юнит-тесты, интеграционные тесты и E2E (end-to-end) тесты. В зависимости от типа тестирования, можно настроить соответствующие этапы и задачи.

Пример конфигурации для разных типов тестирования:

stages:
  - test

unit_tests:
  stage: test
  script:
    - npm run test:unit

integration_tests:
  stage: test
  script:
    - npm run test:integration

e2e_tests:
  stage: test
  script:
    - npm run test:e2e

Каждая из этих задач может быть настроена для выполнения в определённых условиях или на разных окружениях, что позволяет гибко управлять процессом тестирования.

10. Оптимизация работы с кешем

Для ускорения процесса сборки и тестирования можно использовать кеширование зависимостей, таких как node_modules или другие файлы, которые не меняются между сборками.

Пример кеширования зависимостей:

stages:
  - install
  - test

install_dependencies:
  stage: install
  image: node:16
  script:
    - npm install
  cache:
    paths:
      - node_modules/

run_tests:
  stage: test
  script:
    - npm run test
  cache:
    paths:
      - node_modules/

В этом примере node_modules кешируются между сборками, что ускоряет процесс установки зависимостей.

Настройка GitLab CI для WebdriverIO тестирования позволяет значительно ускорить процесс разработки и тестирования. С помощью правильной конфигурации можно эффективно управлять тестами, запускать их в разных браузерах, собирать отчёты и использовать различные окружения.