GitHub Actions: workflows, jobs, steps

Четыре существительных: workflow, job, step, runner

Всё в GitHub Actions — это одна из четырёх вещей. Workflow — это один YAML-файл, лежащий в .github/workflows/ твоего репозитория: ci.yml, deploy.yml, по файлу на workflow. Workflow содержит один или несколько jobs. Каждый job выполняется на runner — виртуальной машине (GitHub-hosted ubuntu-latest или твой self-hosted сервер), которая поднимается с нуля под этот job и уничтожается, когда он заканчивается. Внутри job — упорядоченный список steps, и каждый step делает ровно одно из двух: либо uses: опубликованный action, либо run: shell-команду.

Триггер стоит наверху. Ключ on: объявляет, какие события запускают workflow. Четыре, к которым тянешься постоянно: push (коммит прилетел в ветку), pull_request (PR открыт или обновлён), workflow_dispatch (человек нажал «Run workflow» — кнопка ручного запуска) и schedule (cron-выражение, например ночной прогон). Один workflow может слушать сразу несколько событий.

name: CI
on:
  push:
    branches: [main]
  pull_request:
  workflow_dispatch:        # кнопка ручного запуска
  schedule:
    - cron: '0 3 * * *'     # ночью в 03:00 UTC

jobs:
  test:
    runs-on: ubuntu-latest  # runner: свежая VM
    steps:
      - uses: actions/checkout@v4        # action: клонировать репозиторий
      - uses: actions/setup-node@v4      # action: поставить Node
        with:
          node-version: 22
          cache: npm
      - run: npm ci                      # shell-команда
      - run: npm test

Это полноценный, реальный CI-workflow: на каждый push в main и каждый PR подними свежую Ubuntu-VM, выкачай код, поставь Node 22, детерминированно установи зависимости через npm ci и запусти тесты. actions/checkout и actions/setup-node — канонические первые два шага почти любого Node-workflow: runner стартует пустым, поэтому ты обязан явно склонировать собственный репозиторий и поставить тулчейн, прежде чем что-либо ещё сможет выполниться.

Jobs по умолчанию параллельны и изолированы

Это правило удивляет. Перечисли два job в одном workflow — и они выполнятся одновременно, на отдельных runner’ах. GitHub не сериализует их за тебя. Это фича — твои lint, type-check и тесты завершатся за время самого медленного, а не их суммы, — но это значит, что ни один job не видит файловую систему, окружение или вывод другого. Каждый runner — это чистая VM, которая заканчивается в тот момент, когда заканчивается её job.

Чтобы навязать порядок, используй needs:. Job с needs: [test] не стартует, пока test не завершится успешно, превращая плоское множество jobs в направленный ациклический граф (DAG). Так ты выражаешь «lint и тесты параллельно, потом деплой — только если оба прошли».

jobs:
  lint:
    runs-on: ubuntu-latest
    steps: [{ uses: actions/checkout@v4 }, { run: npm run lint }]
  test:
    runs-on: ubuntu-latest
    steps: [{ uses: actions/checkout@v4 }, { run: npm test }]
  deploy:
    needs: [lint, test]      # ждёт оба; запускается только если оба прошли
    runs-on: ubuntu-latest
    steps: [{ run: ./deploy.sh }]

Поскольку каждый job — это собственная VM, ты не можешь просто передать файл из одного job в следующий. Если build создаёт папку dist/, нужную deploy, то job сборки должен выгрузить её через actions/upload-artifact, а job деплоя — скачать через actions/download-artifact. Аналогично, per-runner кэш (actions/cache или сокращение cache: у setup-node) сохраняет вещи вроде node_modules между прогонами во времени — это не канал для передачи данных между jobs в одном прогоне. Артефакты двигают данные вбок внутри прогона; кэш двигает данные вперёд между прогонами.

Поток одного прогона

Когда срабатывает событие, GitHub читает подходящий файл workflow, строит граф jobs из needs: и отправляет каждый готовый job на runner. Внутри каждого runner steps выполняются сверху вниз, и первый упавший шаг (ненулевой код выхода) роняет job, если ты не отказался от этого явно. Вот вся цепочка от начала до конца.