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 для оптимизации
Итак, это все! Я надеюсь, что вы нашли это полезным. Вы можете узнать больше об автоматизированной сборке и тестировании из официальной документации здесь.
До следующего раза :) Приятного обучения!
Билал К.