Задания в воркфлоу обозначают какую-то часть процесса интеграции — например, сборку, тестирование, деплой и тому подобное. По умолчанию задания запускаются параллельно, но если нужно, то их можно упорядочивать:
# сборка фронтенда и бекенда происходит одновременно
# а тесты бекенда запускаются только после сборки бекенда
jobs:
build-frontend:
build-backend:
test:
needs: build-backend
Задание test запустится только в том случае, если build-backend завершился без ошибок. Иногда задание нужно выполнять в любом случае, независимо от результата выполнения предыдущих. Типичный пример – нотификация. Для этого добавляется специальная конструкция через ключ if
:
jobs:
build-frontend:
build-backend:
test:
# конструкция внутри ${{}} называется выражением
if: ${{ always() }}
needs: build-backend
Для обеспечения параллельности Github запускает задания в независимых директориях. Файлы, которые создает конкретное задание, не видно из других заданий. Если во время сборки build-backend у нас на диске оказались какие-то файлы, то задание test их не увидит. Для этого нужно дополнительно включать шаги по переносу данных из одного задания в другое. Поэтому для проектов с простой структурой достаточно создать одно задание, которое делает сразу все:
# Пример для проекта на Node.js
jobs:
build: # имя взято для примера
runs-on: ubuntu-latest
steps:
# Клонируем репозиторий
- uses: actions/checkout@v4
# Устанавливаем Node.js
- uses: actions/setup-node@v4
# Ставим зависимости
- run: npm install
# Запускаем линтер
- run: npm run lint
# Запускаем тесты
# у шагов может быть имя, иногда это помогает отладке
# имя выводится на Github при просмотре сборки
- name: run tests
run: npm test # name и run относятся к одной задаче, поэтому дефис ставится только перед name
Каждый шаг задания запускается в одной и той же директории. Туда же клонируется репозиторий экшеном checkout.
Операционная система
Github Actions позволяет выбрать одну из трех операционных систем: Ubuntu, Windows и MacOS. Все возможные варианты перечислены на специальной странице. В большинстве случаев для запуска используется ubuntu-latest. А что если мы хотим тестировать код на разных операционных системах? Самый дубовый вариант – создать идентичные задания под каждую операционную систему, но можно лучше.
В Github Actions встроена возможность описать одно задание так, чтобы оно запускалось для разных версий операционных систем, языков и так далее:
jobs:
build:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, macos-latest]
steps:
# тут шаги
Переменные окружения
С помощью ключа env
можно добавить переменные окружения, доступные для всех шагов текущего задания:
jobs:
run:
env:
RAILS_ENV: staging
DEBUG: 1
Довольно много полезных переменных окружения добавлено сразу. Вот как их можно использовать прямо в шагах:
steps:
- run: echo "Имя текущего воркфлоу – $GITHUB_WORKFLOW"
Точно так же переменные можно определять или переопределять в конкретных шагах:
steps:
- run: echo "$key"
env:
# Если такой ключ определен на уровне задания,
# то он будет переопределен текущим значением
key: value
Самостоятельная работа
В этой самостоятельной мы сделаем воркфлоу для рабочего приложения.
-
Форкните репозиторий hexlet-ci-app
-
Изучите ридми репозитория
-
Создайте воркфлоу. В нем должны быть:
-
make setup
— сетап проекта -
make test
— запуск тестов -
make lint
— запуск линтера
-
-
Запушьте все изменения на гитхаб и проверьте, что воркфлоу выполнился успешно
-
Добавьте в README.md бейдж со ссылкой на Github Actions
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
- Статья «Как учиться и справляться с негативными мыслями»
- Статья «Ловушки обучения»
- Статья «Сложные простые задачи по программированию»
- Вебинар «Как самостоятельно учиться»
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.