Jobs, steps и runners

Глубже разбираем, как jobs распараллеливаются и на каких машинах живут.

Runner — это сервер с установленным агентом GitHub Actions, который берёт job из очереди и выполняет его шаги.

Job — единица параллелизма

Каждый job выполняется на своём отдельном runner. По умолчанию все jobs одного workflow стартуют параллельно. Это удобно: линтер, тесты и сборка для разных платформ идут одновременно и не ждут друг друга.

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "проверяю стиль кода"

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "гоняю тесты"

Здесь lint и test запустятся одновременно на двух разных машинах.

Выбор runner через runs-on

Ключ runs-on задаёт операционную систему. GitHub предоставляет три семейства:

Для своих машин (доступ во внутреннюю сеть, особое железо) используют self-hosted раннеры с метками вроде runs-on: self-hosted.

Steps выполняются по порядку

В отличие от jobs, steps внутри одного job всегда идут строго последовательно, сверху вниз. Если шаг упал, по умолчанию следующие шаги не выполняются, и весь job помечается как failed. Состояние файловой системы и установленные программы сохраняются между шагами одного job — это и позволяет сначала поставить зависимости, а потом запустить тесты.

Изоляция между jobs

А вот между разными jobs ничего не сохраняется: каждый получает чистый runner. Если job build собрал файлы, а job deploy хочет их забрать — нужно явно передать данные через артефакты (загрузить в одном, скачать в другом) или объявить зависимость через needs (об этом в разделе про CD).

Итог

• Jobs по умолчанию параллельны и изолированы; steps внутри job — последовательны и делят файловую систему.
• runs-on выбирает ОС runner: ubuntu/windows/macos или self-hosted.
• Передача данных между jobs — только явно (артефакты, needs).