Что делает
Автоматизирует сборку, проверки и деплой прямо в GitHub: конвейеры на YAML запускаются на события репозитория и выполняются на предоставляемых машинах.
Live-данные · обновлено 19 июля 2026 г.
GitHub Actions
GitHub Actions — встроенная в GitHub платформа CI/CD: автоматизация сборки, проверок и деплоя через YAML-файлы прямо в репозитории. Конвейеры запускаются на события — от пуша до релиза — без отдельного CI-сервера.
КВКузнецов Вячеслав·Технический редактор·DevOps/SRE-техлид · опыт 10+ лет
Вакансий
89
активных в Москве
Медиана зарплаты
—
Индекс спроса
59/100
#137 из 332 навыков
Доля IT-рынка
1.3%
24 профессий
Коротко о навыке
GitHub Actions — система непрерывной интеграции и доставки, встроенная прямо в GitHub. Конвейеры описываются YAML-файлами в папке .github/workflows и запускаются на события репозитория: пуш, pull request, релиз, расписание, ручной триггер. Не нужен отдельный CI-сервер — GitHub предоставляет вычислительные машины (runners), на которых выполняются задачи.
Сила платформы — в marketplace готовых действий (actions): типовые шаги вроде checkout кода, установки языка или деплоя переиспользуются одной строкой. Иерархия проста: конвейер состоит из задач (jobs), задача — из шагов (steps), шаг вызывает действие или команду. Чаще всего GitHub Actions спрашивают с DevOps-инженеров и разработчиков, автоматизирующих проверки и выкатку своего кода.
Для этого навыка доступны ограниченные данные (менее 50 вакансий или нет зарплатных данных). Аналитика носит ориентировочный характер.
Что такое GitHub Actions
Кто использует
DevOps-инженеры строят конвейеры доставки; разработчики автоматизируют проверки и выкатку своего кода — GitHub Actions доступен любому проекту на GitHub.
Позиция на рынке
Стандарт CI/CD для проектов на GitHub. Доминирующая роль — DevOps-инженер; в парах Docker, Kubernetes и облачные платформы деплоя.
Что такое GitHub Actions
GitHub Actions — платформа автоматизации, интегрированная в GitHub. Вместо настройки внешнего CI-сервера (Jenkins, отдельный GitLab) конвейер описывается YAML-файлом в самом репозитории и живёт рядом с кодом. При наступлении события — пуш, pull request, создание релиза — GitHub запускает конвейер на своей виртуальной машине. Это убрало барьер входа в CI/CD: любой проект на GitHub получает автоматизацию без инфраструктуры, а публичные репозитории — бесплатно.
Анатомия конвейера
Иерархия из четырёх уровней. Workflow — весь конвейер, один YAML-файл, запускаемый на события. Job — задача внутри конвейера, выполняется на отдельной машине; задачи по умолчанию идут параллельно, но можно задать зависимости. Step — шаг внутри задачи, выполняется последовательно. Action — переиспользуемый компонент, вызываемый шагом (например, actions/checkout для получения кода). Понимание этой иерархии — основа чтения и написания любого конвейера.
Триггеры и runners
Секция on задаёт события запуска: push и pull_request по веткам, release, schedule по расписанию (cron), workflow_dispatch для ручного запуска. Runner — машина, на которой выполняется задача: GitHub даёт готовые (ubuntu-latest, windows, macos), а для особых нужд подключают собственные (self-hosted). Правильный выбор триггеров определяет, когда конвейер запускается, а runner — где и с какими ресурсами он выполняется.
Понятия / Карта
Из чего состоит GitHub Actions
Понятие Что это Что нужно уметь
Workflow
Весь конвейер в одном YAML-файле, запускаемый на события.
Проектировать конвейеры под задачи, разносить логику по файлам, переиспользовать.
Job
Задача конвейера, выполняется на отдельной машине.
Управлять параллельностью и зависимостями задач через needs, выбирать runners.
Step / Action
Шаг задачи и готовый компонент, который он вызывает.
Комбинировать команды и действия marketplace, фиксировать их версии.
Триггеры (on)
События, запускающие конвейер: пуш, PR, расписание.
Настраивать точные условия запуска, различать безопасные триггеры для форков.
secrets / OIDC
Безопасное хранение токенов и временный доступ к облаку.
Работать через secrets, переходить на OIDC, минимизировать права токена.
Matrix
Запуск задачи в нескольких вариантах параллельно.
Проверять совместимость по версиям и ОС одним описанием без дублирования.
Механика / Работа
Как работает конвейер GitHub Actions
Путь от события в репозитории до результата на предоставленной машине.
Шаг Слой Смысл
Шаг 01
Событие запускает конвейер
Пуш, pull request или расписание, указанные в секции on, запускают workflow; GitHub выделяет виртуальную машину (runner) для выполнения его задач.
Шаг 02
Задачи выполняют шаги
Каждая задача на своей машине проходит шаги: получает код, ставит зависимости, вызывает действия marketplace и команды — параллельно или по заданным зависимостям.
Шаг 03
Результат возвращается в репозиторий
Статус конвейера отображается в pull request и коммите, артефакты сохраняются, деплой выкатывает приложение — команда сразу видит итог прямо в GitHub.
Карьера / Роли
Кому нужен GitHub Actions
GitHub Actions переносится между ролями: DevOps-инженер, Python-разработчик, Бэкенд-разработчик. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.
Роли с GitHub Actions за период
DevOps-инженер держит 95.5% вакансий по навыку.
Роль Упоминаний за период Медиана
Ещё 7 ролей используют GitHub Actions
Текущий срез показывает активные вакансии сейчас. Распределение по ролям рассчитано по расширенной исторической выборке, поэтому значения могут быть выше текущего количества активных вакансий.
Практика / Задачи
Частые задачи с GitHub Actions
GitHub Actions ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами — ниже они разобраны так, как встречаются в реальной работе.
# Задача Что делает специалист
Задача 01
Базовый конвейер проверок
Минимальный workflow: тесты и линтер на каждый push и pull request.
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main]
pull_request:
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: Установка зависимостей
run: pip install -r requirements.txt
- name: Проверки
run: |
pytest
ruff check .
Задача 02
Матричная сборка
Один job проверяет код на нескольких версиях языка параллельно.
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
python: ["3.10", "3.11", "3.12"]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python }}
- run: pytest
# один блок -> три параллельных прогона
# по каждой версии Python
Задача 03
Секреты в конвейере
Токены подставляются из secrets репозитория, а не хранятся в коде.
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Логин в реестр
run: |
echo "${{ secrets.REGISTRY_TOKEN }}" \
| docker login registry.example.com \
-u ci --password-stdin
- name: Сборка и публикация
run: |
docker build -t registry.example.com/app:${{ github.sha }} .
docker push registry.example.com/app:${{ github.sha }}
Задача 04
Деплой через OIDC
Временный токен доступа к облаку вместо долгоживущего ключа — современный стандарт безопасности.
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write # разрешить запрос OIDC-токена
contents: read
steps:
- uses: actions/checkout@v4
# облако доверяет этому репозиторию через OIDC;
# ключи НЕ хранятся в secrets вообще
- name: Настройка доступа к облаку
uses: cloud-provider/configure@v1
with:
role-to-assume: arn:...:role/deployer
audience: sts.cloud
Задача 05
Кэширование зависимостей
Кэш ускоряет прогоны, не скачивая зависимости заново каждый раз.
steps:
- uses: actions/checkout@v4
- name: Кэш зависимостей
uses: actions/cache@v4
with:
path: ~/.cache/pip
key: pip-${{ hashFiles('requirements.txt') }}
restore-keys: pip-
- run: pip install -r requirements.txt
# при неизменных зависимостях установка
# берётся из кэша за секунды
Задача 06
Зависимости между задачами
needs выстраивает порядок: деплой только после успешной сборки.
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo "собираем"
deploy:
needs: build # ждёт успешного build
runs-on: ubuntu-latest
environment: production # требует подтверждения
steps:
- run: echo "выкатываем"
# без needs задачи выполнялись бы параллельноПрактика / Ошибки
Ошибки новичков
Ошибка 01
Секреты в коде конвейера
Вписать токен прямо в YAML вместо secrets — утечка: файл в репозитории виден всем с доступом, а в публичном — миру. Все чувствительные значения только через secrets, а лучше — OIDC без долгоживущих ключей вовсе.
Ошибка 02
Доступ к секретам из форков
Конвейер на pull_request от форка с доступом к secrets — дыра: чужой код в PR может их украсть. Для форков использовать pull_request (без секретов), а не pull_request_target без крайней осторожности.
Ошибка 03
Незакреплённые версии действий
uses: some/action@main тянет свежую версию, которая может сломаться или оказаться скомпрометированной. Фиксировать версии тегом (@v4) или SHA — защита от неожиданных изменений и атак на цепочку.
Ошибка 04
Избыточные права токена
Оставлять конвейеру полные права по умолчанию — лишний риск при компрометации. Задавать минимальные permissions на уровне конвейера или задачи: только то, что реально нужно этому процессу.
Ошибка 05
Конвейеры без кэша
Скачивать и собирать зависимости заново каждый прогон — минуты впустую и лишняя стоимость. Кэширование зависимостей и артефактов между задачами кратно ускоряет конвейер — базовая оптимизация.
Рынок / Контекст
Рынок GitHub Actions: контекст спроса
GitHub Actions — стандарт CI/CD для проектов, живущих на GitHub, и это определяет спрос. Доминирующая роль — DevOps-инженер, но конвейеры пишут и разработчики: автопроверки своего кода стали нормой. Работодатель ждёт не копипаста готовых конвейеров, а понимания структуры workflow/job/step, безопасной работы с секретами и OIDC, матричных сборок. В парах GitHub Actions идёт с Docker, Kubernetes и облачными платформами деплоя.
Сокращает ручную работу
GitHub Actions востребован там, где инструмент реально ускоряет повторяемые задачи команды, а не существует отдельной теорией.
Встроен в рабочий процесс
Спрос держится дольше, когда навык нужен не эпизодически, а как часть ежедневного цикла разработки, проверки или доставки.
Закреплён в зрелом стеке
GitHub Actions чаще ищут там, где процесс уже стандартизирован и без этого инструмента команда теряет скорость и предсказуемость.
Сигнал рынка
Стабильный спрос
GitHub Actions формирует устойчивый спрос внутри своего рабочего сегмента.
Рынок / Спрос
Спрос на GitHub Actions на рынке
GitHub Actions сохраняет устойчивый прикладной спрос на рынке: 89 активных вакансий, #137 по рынку, 1.3% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.
Сила спроса
Стабильный спрос 89
активных вакансий сейчас
#137 по рынку • 1.3% IT-вакансий
Месяц к месяцу
129
июль 2026 — предварительный накопительный срез
-13 вакансий и -9% к предыдущему месяцу.
Связи / Навыки
Навыки в связке с GitHub Actions
GitHub Actions редко живёт изолированно: чаще всего рынок видит его рядом с GitHub, CI/CD, GitLab. Самая плотная связка сейчас - GitHub: оба навыка встречаются вместе в 100% вакансий.
Главная связка: GitHub • 100% вакансий. Показываем общерыночные связки GitHub Actions: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.
Рабочий стек вокруг GitHub Actions
навыки, которые рынок чаще всего видит рядом в одной вакансии
Навык Зачем рядом Доля
Вход / Старт
Порог входа
Сейчас на рынке 5 активных junior-вакансий с GitHub Actions. Это 6.2% всех вакансий по навыку, поэтому для старта важнее всего смотреть на реальный объём junior-окна и на стек, который рынок ждёт рядом.
Junior-вакансии сейчас
5
активных вакансий
6.2% всех вакансий по навыку • Senior / Junior 7.9x
Доля junior
6.2%
% всех вакансий по навыку
Окно входа узкое: рынок чаще нанимает с опытом.
Что нужно на старте
Стартовый стек
23
навыков в медианной вакансии
Медианная вакансия с GitHub Actions ожидает около 23 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.
Карьера / Резюме
GitHub Actions в резюме: что значит "знаю GitHub Actions"
Владение GitHub Actions по-разному отражается в резюме в зависимости от уровня. Ниже — что это означает и что показать для каждого грейда.
Уровень Что значит Что показать
Beginner
Знаю, что такое workflow, могу создать простой пайплайн из одного job'а.
Пример workflow Hello World с checkout и шагом echo.
Junior developer
Создаю workflows с matrix, кешем, использую marketplace actions.
CI-пайплайн для проекта с автотестами, линтером и деплоем на staging.
Middle developer
Проектирую multi-job пайплайны с зависимостями, продуктивно использую reusable workflows.
Сложный CI/CD с Docker, K8s, security scanning, автоматическими релизами.
Senior developer
Настраиваю self-hosted runners, пишу composite actions, обеспечиваю безопасность workflows.
Архитектура CI/CD для микросервисной архитектуры, управление runner'ами, политики безопасности.
QA automation
Интегрирую E2E-тесты в workflow, настраиваю параллельный запуск и Allure-отчёты.
Workflow, запускающий Cypress/Playwright на PR с блоками слияния при падении.
Data/ML
Автоматизирую обучение моделей, сборку датасетов, использую Actions по расписанию.
Workflow для переобучения модели на GPU-runner с сохранением весов.
DevOps junior
Строю базовый CI/CD для одного сервиса, использую Docker actions.
Пайплайн сборки и публикации Docker-образа, деплой на staging.
SRE/platform
Управляю self-hosted runner'ами, пишу сложные reusable workflows, мониторю производительность.
Архитектура CI/CD с zero-downtime deploy, многоокруженная система и SLA.
Сравнение / Инструменты
GitHub Actions в DevOps-стеке
С чем платформа работает в связке в реальных проектах.
Инструмент За что отвечает Когда нужен Граница
Docker
Сборка и публикация образов в конвейере
Практически любой современный сервис
Сборка образов заметно замедляет прогон без кэша.
Kubernetes
Цель деплоя из конвейера
Выкатка контейнеризованных приложений
Доступ к кластеру настраивается безопасно через OIDC.
Облачные платформы
Деплой инфраструктуры и приложений
Выкатка в AWS, Yandex Cloud и другие
Долгоживущие ключи — антипаттерн, использовать OIDC.
Marketplace actions
Готовые компоненты для типовых шагов
Стандартные операции конвейера
Чужие действия — вектор атаки, версии фиксировать.
Terraform
Инфраструктура как код в конвейере
Автоматизация изменений инфраструктуры
Plan и apply в CI требуют аккуратной работы с состоянием.
Навык / Применение
Где используется GitHub Actions
GitHub Actions применяется для автоматизации всего пути кода — от проверки при каждом изменении до выкатки в продакшн.
Сценарий 01
Автопроверки на pull request
При каждом PR запускаются тесты, линтеры и проверка типов: код не вливается в основную ветку, пока проверки не прошли — базовая гигиена командной разработки.
Сценарий 03
Деплой в облако
После проверок конвейер выкатывает приложение в Kubernetes или облако через OIDC без вшитых ключей: полный путь от коммита до продакшна автоматически.
Сценарий 04
Матричное тестирование
Проверка совместимости на нескольких версиях языка и операционных систем одновременно: одна матрица порождает параллельные прогоны по всем комбинациям.
По направлениям
GitHub Actions заметен в 4 направлениях рынка с долей выше 5%.
Направление Контекст Доля
Разработка
Автоматическая сборка и тестирование при каждом коммите. Деплой на staging через SSH или FTP.
43.7%
Инфраструктура
Full CI/CD: Docker-образы, Kubernetes, матрица K8s, инфраструктурные actions (Terraform, релизы).
28.3%
Тестирование
Часть спроса по навыку сосредоточена в этом направлении.
12%
Данные и ML
Часть спроса по навыку сосредоточена в этом направлении.
8.7%
Направления показывают, в каких частях IT-рынка навык заметен чаще всего, без разбивки по ролям.
Инструмент / Возможности
Что умеет GitHub Actions
Возможности, сделавшие платформу стандартом CI/CD на GitHub.
CI/CD без инфраструктуры
Конвейер живёт в репозитории и выполняется на машинах GitHub — не нужно поднимать и обслуживать отдельный CI-сервер.
Marketplace действий
Тысячи готовых компонентов для типовых шагов — checkout, установка языка, деплой — вызываются одной строкой uses.
Матричные сборки
Одна задача проверяется в множестве вариантов версий и ОС параллельно — совместимость без дублирования конвейера.
Безопасный деплой
Секреты хранятся отдельно от кода, а OIDC даёт доступ к облаку временным токеном без долгоживущих ключей.
Сравнение / Контекст
GitHub Actions vs GitLab CI vs Jenkins
Три инструмента CI/CD — выбор чаще определяет платформа.
GitHub Actions vs GitLab CI
Обе — встроенные в свою платформу CI/CD с похожей YAML-моделью (задачи, шаги). Выбор чаще определяет, где живёт код: GitHub — Actions, GitLab — GitLab CI. GitHub Actions выигрывает marketplace...
GitHub Actions vs Jenkins
Jenkins — мощный самостоятельный CI-сервер с плагинами, но его нужно устанавливать и обслуживать. GitHub Actions встроен и не требует инфраструктуры. Jenkins держится в enterprise со сложными...
GitHub Actions vs CircleCI
CircleCI — внешний CI-сервис, интегрируемый с репозиторием, исторически силён скоростью и гибкостью настройки. GitHub Actions выигрывает нулевой интеграцией для GitHub-проектов и marketplace. Для...
Практика / Workflow
Как GitHub Actions используется в реальном проекте
Этап Что происходит Артефакт
1 Событие
Пуш, pull request, релиз, расписание
Запуск конвейера
2 Задачи
Jobs на runners, параллельно или по needs
Распределённое выполнение
3 Шаги
Действия marketplace и команды
Сборка, проверки, артефакты
4 Секреты
secrets или OIDC-токен
Безопасный доступ к ресурсам
5 Деплой
Выкатка в облако или Kubernetes
Обновлённый продакшн
6 Обратная связь
Статус в PR, логи, уведомления
Видимость результата
Инструмент / Оркестрация
GitHub Actions: запуск workflow и структура YAML
Workflow GitHub Actions описывается в YAML-файлах. Рассмотрим ключевые элементы на примере типового CI-пайплайна.
events / триггеры
Событие, запускающее workflow: push, pull_request, schedule, release, workflow_dispatch. Уточняется ветками и путями.
jobs / шаги пайплайна
Одна или несколько задач. Каждая выполняется на своём runner. Порядок задаётся через needs.
steps / последовательность действий
Шаги внутри job: shell-команды (run) или готовые actions (uses). Выполняются последовательно.
actions / переиспользуемые блоки
Готовые actions из Marketplace: checkout, setup-node, cache, docker/login-action. Фиксируются по версии (@v4).
matrix / параллельные конфигурации
Матрица параметров (ОС, версия языка) для параллельного запуска одного job с разными настройками.
secrets / безопасность
Зашифрованные переменные (токены, пароли). Доступны через ${{ secrets.NAME }}. Указываются в настройках репозитория.
Практика / GitHub Actions
GitHub Actions: лучшие практики и типичные ошибки новичков
Практика 01
Фиксируйте версии actions
Используйте @v4 или точный SHA-коммит, никогда @main или @latest. Иначе обновление action сломает workflow.
Практика 02
Минимизируйте количество шагов
Объединяйте команды в один run через && или отдельный скрипт. Каждый шаг — это отдельный процесс и потенциально сетевой запрос (скачивание action). Слишком много мелких шагов увеличивает накладные...
Практика 03
Используйте cache зависимостей
Кешируйте npm, pip, Maven через actions/cache. Сокращает время с 5–10 минут до 30–60 секунд.
Практика 04
Не храните секреты в YAML
Даже приватный файл может быть скомпрометирован. Используйте secrets GitHub.
Практика 05
Добавляйте timeout-minutes
Предотвращает зависание workflow — задайте timeout-minutes: 10 для каждого job.
Практика 06
Проверяйте actions на безопасность
Перед использованием стороннего action изучите код и рейтинг, сканируйте зависимости через actions/dependency-review-action.
Практика 07
Используйте minimum permissions
Явно задавайте permissions в YAML: contents: read, packages: write. Не выдавайте лишние права.
Практика 08
Разделяйте большие workflow
Для сложных пайплайнов используйте reusable workflows или разбивайте на несколько файлов.
Практика / Безопасность
Безопасность GitHub Actions: что нельзя делать
Риск 01
pull_request_target без защиты
Этот event даёт полный доступ к секретам. Используйте с осторожностью — ограничьте действия safe-list или проверяйте через действия.
Риск 02
Инъекции через event payload
Не подставляйте github.event.issue.title в run: без экранирования. Экранируйте через ${{ ... }}.
Риск 03
Избыточные permissions по умолчанию
По умолчанию contents: write. Ограничьте через permissions: contents: read, packages: write.
Риск 04
Секреты в action'ах с параметрами
Не передавайте GITHUB_TOKEN в action, который принимает token — используйте его только внутри workflow.
Риск 05
Несканированные образы и зависимости
Добавьте dependency-review-action и Trivy (aquasecurity/trivy-action) для проверки уязвимостей.
Риск 06
Запуск workflows на чужих PR без одобрения
Настройте approval для новых контрибьюторов или используйте pull_request с minimal permissions.
Риск 07
Используйте OIDC вместо статических токенов
OIDC позволяет временным токенам доступа к облакам без хранения долгоживущих секретов.
Риск 08
Не обновляйте actions без проверки
Автоматическое обновление (dependabot) может подхватить вредоносную версию — проверяйте changelog.
Будущее / Роль
Перспективы GitHub Actions
Перспективы GitHub Actions завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.
Сигнал 01
OIDC вытесняет ключи
Доступ к облаку через временные OIDC-токены вместо долгоживущих секретов становится стандартом безопасности CI/CD. Хранение облачных ключей в secrets постепенно уходит как...
Сигнал 02
Безопасность цепочки поставки
Атаки через скомпрометированные действия marketplace усилили внимание к supply-chain: фиксация версий по SHA, подпись артефактов, проверка зависимостей встраиваются в...
Сигнал 03
AI в конвейерах
Автоматический разбор упавших прогонов, генерация конвейеров и предложения по оптимизации на основе AI ускоряют работу. Инструменты меняются, но понимание структуры и...
Практика / Портфолио
Портфолио с GitHub Actions: с чего начать
Проект 01
Полный конвейер CI/CD
Репозиторий с конвейером от проверок до деплоя: тесты и линтеры на PR, матричная сборка, кэширование, публикация Docker-образа, выкатка через OIDC без вшитых ключей, окружение с подтверждением. Показывает владение всей...
Проект 02
Переиспользуемый конвейер команды
Reusable workflow и composite action, вынесенные в отдельный репозиторий и вызываемые из нескольких проектов: единый безопасный процесс сборки для команды. Демонстрирует зрелый подход против копипаста конвейеров.
Обучение / Маршрут
Как изучить GitHub Actions
Первый рабочий конвейер на GitHub Actions пишется за час по примерам. Настоящий навык — безопасность, матрицы, переиспользование, оптимизация — набирается на реальных репозиториях.
Этап Фокус Что изучать
Этап 01
Первый конвейер
Создать .github/workflows/ci.yml, запустить тесты на push. Понять базовую структуру: on, jobs, steps, uses и run. Первый зелёный прогон.
Этап 02
Анатомия и триггеры
Иерархия workflow → job → step → action, события (push, pull_request, schedule), зависимости между задачами (needs). Осознанно управлять запуском.
Этап 03
Действия из marketplace
checkout, setup-языка, кэширование зависимостей, сборка Docker. Понять, как переиспользовать готовые действия и зачем фиксировать их версии.
Этап 04
Секреты и безопасность
Хранение токенов в secrets, подстановка в YAML, минимум прав (permissions), опасность форков в pull_request. OIDC вместо долгоживущих ключей.
Курсы · по данным рынка
Где учить GitHub Actions
Соответствие — доля тем навыка, которые охватывает программа курса
Практика / Первый запуск
Как начать изучать GitHub Actions
Три шага от первого конвейера до безопасного деплоя.
Шаг 01
Написать первый конвейер
Создать .github/workflows/ci.yml, запустить тесты на push. Понять базу: on, jobs, steps, uses и run. Первый зелёный прогон — за час по примерам из документации.
Шаг 02
Разобраться в структуре и действиях
Иерархия workflow/job/step, триггеры, действия marketplace, зависимости через needs, матрицы. Собрать конвейер сборки и публикации образа.
Шаг 03
Освоить безопасность и деплой
Секреты, минимум прав, OIDC вместо ключей, окружения с подтверждением. Настроить деплой из конвейера — навык, который проверяют на собеседовании.
Старт / Документация
Официальные ресурсы и быстрый старт
Для инструментов вроде GitHub Actions на одной странице полезно держать и объяснение роли на рынке, и быстрые переходы к официальным ресурсам.
Частые вопросы
Вопросы и ответы
Что такое GitHub Actions простыми словами?
Встроенная в GitHub система автоматизации: описываешь в YAML-файле, что делать при событиях репозитория (пуш, pull request), и GitHub сам это выполняет на своей машине — собирает, проверяет, деплоит. CI/CD без отдельного сервера, прямо рядом с кодом.
Как устроен конвейер (workflow)?
Иерархия из четырёх уровней: workflow — весь конвейер (один YAML-файл); job — задача, выполняется на отдельной машине, задачи идут параллельно; step — шаг внутри задачи, последовательно; action — готовый переиспользуемый компонент, вызываемый шагом. Понимание этой структуры — основа работы.
GitHub Actions или GitLab CI?
Чаще решает платформа хостинга: проект на GitHub — Actions, на GitLab — GitLab CI. Концептуально они очень близки (YAML, задачи, шаги). GitHub Actions выигрывает marketplace готовых действий; навыки между ними хорошо переносятся.
Как безопасно хранить токены?
Только в secrets репозитория, никогда в коде конвейера — в YAML подставляются как ${{ secrets.NAME }}. Ещё лучше — OIDC: конвейер получает временный токен доступа к облаку на время выполнения, и долгоживущие ключи хранить не нужно вовсе.
Что такое OIDC в GitHub Actions?
Механизм, при котором облако доверяет конвейеру и выдаёт временный токен доступа на время прогона вместо постоянного ключа в secrets. Это устраняет риск утечки долгоживущих ключей — современный стандарт безопасного деплоя из CI.
Что такое матричные сборки?
strategy.matrix запускает одну задачу в нескольких вариантах параллельно — например, тесты на разных версиях языка и ОС. Одно описание порождает все комбинации как отдельные прогоны: эффективная проверка совместимости без дублирования конвейера.
Нужен ли отдельный сервер для GitHub Actions?
Нет: GitHub предоставляет виртуальные машины (runners) для выполнения задач, публичным репозиториям — бесплатно в пределах лимитов. Свои runners (self-hosted) подключают лишь при особых нуждах — специфичное железо, закрытая сеть, большие объёмы.