GitHub Actions — это мощная и гибкая платформа автоматизации CI/CD, которая позволяет разработчикам создавать, тестировать и развертывать программные приложения прямо из своих репозиториев GitHub.

Мы часто забываем запустить тестовые примеры перед слиянием кода с основной веткой. Если зафиксированный код неисправен и не проходит все написанные тестовые случаи, кодовая база сломается и может привести к большим проблемам в рабочей среде.
В этом посте мы узнаем, как использовать Github Actions для запустите модульные тесты перед созданием нового запроса на включение, чтобы увидеть, все ли тесты пройдены в коде. Это сэкономит время, и ничего сломанного не будет отправлено в ветку. Давайте углубимся.

Подход.

  • определить точку срабатывания, когда запускать рабочий процесс CI (например, pull_request).
  • определить версию узла.
  • Получите кеш, чтобы ускорить процесс.
  • Установите зависимости, если они не кэшированы.
  • Запустите тесты.

Для начала добавьте начальный рабочий процесс в каталог .github/workflows вашего репозитория.

Итак, что мы только что сделали выше? Мы пройдемся по файлу конфигурации и поймем, что мы на самом деле делаем.

  • Начиная сверху, мы сначала указываем наше имя, используя: name: Github-CI
  • on: [push, pull_request]: Клавишей -on мы указываем, какие события запускают наше действие. Здесь мы просто говорим, что хотим, чтобы это действие выполнялось, кто-то отправляет коммиты в любую ветку или кто-то создает запрос на извлечение.
  • runs-on: ubuntu-latest& node-version: [16.x]: Давайте объявим версию машины и узла, на которой мы хотим запустить тесты. Я запускаю скрипт в последней версии Ubuntu, а версия Matrix Node установлена ​​на 16.x. Мы можем запустить тесты на нескольких версиях узлов, чтобы убедиться, что все работает и совместимо с разными системами.

Наконец, мы указываем шаги, которые мы хотим, чтобы наша работа выполнялась.

  • uses: actions/checkout@v2: Это проверяет, доступен ли наш код в нашей рабочей среде, чтобы мы могли использовать его для запуска тестов.
  • uses: actions/setup-node@v3: Поскольку мы используем узел в нашем проекте, нам нужно настроить его в нашей среде. Мы используем это действие, чтобы выполнить эту настройку для нас для каждой версии, которую мы указали в матрице, которую мы настроили выше.
  • run: npm install -g yarn& run: yarn install — frozen-lockfile: Мы установим пряжу и другие зависимости проекта. Мы объявили флаг frost-lockfile, чтобы убедиться, что установлена ​​правильная версия требуемых зависимостей. Флаг if выполняет то, на что он похож, и запускает эту команду только в том случае, если требуемые зависимости не найдены в кеше.
  • run:npx nx test api — bail — parallel — maxWorkers=2: Теперь запустим тестовый скрипт в нашем проекте с флагами bail parallel и maxWorkers для оптимизации

Итак, это все! Я надеюсь, что вы нашли это полезным. Вы можете узнать больше об автоматизированной сборке и тестировании из официальной документации здесь.

До следующего раза :) Приятного обучения!

Билал К.