GitHub Actions, платформа автоматизации разработки от GitHub, получила три обновления в начале сентября 2026 года. Изменения касаются управления версиями раннеров, безопасности токенов и работы с переиспользуемыми workflow. Для команд, использующих Actions в продакшене, это означает более предсказуемое обновление инфраструктуры и меньший риск случайного расширения прав доступа.
Новый REST API для отслеживания устаревания версий раннеров
Одно из частых узких мест в CI/CD — неожиданное прекращение поддержки раннеров. Ранее разработчики узнавали об этом из уведомлений или документации, но не имели программного способа проверки. Новый эндпоинт GET /actions/runners/deprecations/{version} на уровне репозитория, организации или предприятия возвращает три поля:
- runner_version — версия раннера;
- runtime_deprecates_at — дата окончания поддержки выполнения задач;
- registration_deprecates_at — дата окончания регистрации новых раннеров этой версии.
Это позволяет встраивать проверку актуальности в пайплайны или скрипты мониторинга. Команды могут планировать обновление до того, как версия будет официально помечена как устаревшая, избегая простоев.
Чтение Dependabot-алертов через GITHUB_TOKEN
Второе изменение касается безопасности. Ранее для доступа к Dependabot-алертам из workflow требовались токены с широкими правами, что нарушало принцип наименьших привилегий. Теперь в permissions для GITHUB_TOKEN добавлено значение vulnerability-alerts, которое поддерживает два уровня: read и none.
Это значит, что workflow может получать информацию об уязвимостях в зависимостях без полного доступа к репозиторию. Например, можно настроить автоматическое создание issues или уведомлений на основе алертов, не открывая доступ к коду. Изменение особенно актуально для организаций с жёсткими требованиями к безопасности.
Ключевые факты
| Что изменилось | Для кого | Зачем |
|---|---|---|
| REST API для проверки дат устаревания раннеров | Администраторы CI/CD, DevOps-инженеры | Планирование обновлений, предотвращение простоев |
| Разрешение vulnerability-alerts для GITHUB_TOKEN | Разработчики, команды безопасности | Безопасный доступ к Dependabot-алертам без расширения прав |
| Свойства job.workflow_ref, job.workflow_sha и другие для переиспользуемых workflow | Разработчики, использующие reusable workflows | Идентификация источника workflow в рантайме |
Идентификация источника в переиспользуемых рабочих процессах
Третье обновление касается переиспользуемых workflow. Ранее для определения того, из какого workflow был вызван текущий джоб, разработчики использовали github.workflow_ref и github.workflow_sha. Однако эти свойства всегда отражали вызывающий workflow, а не тот, в котором определён текущий джоб.
Теперь в job context добавлены четыре новых свойства: job.workflow_ref, job.workflow_sha, job.workflow_name и job.workflow_run_id. Для джобов, определённых непосредственно в вызывающем workflow, job.workflow_ref совпадает с github.workflow_ref. Расхождение возникает только для переиспользуемых workflow — в этом случае job.workflow_ref указывает на файл, в котором определён текущий джоб.
Это упрощает логику в сложных пайплайнах, где один переиспользуемый workflow вызывается из разных мест. Разработчики могут проверять, какой именно workflow выполняется, и адаптировать поведение без передачи дополнительных параметров.
Ограничения и совместимость
Важно учесть, что новые свойства job context недоступны на GitHub Enterprise Server. Они работают только на github.com. Также обновления не требуют изменений в существующих workflow — новые возможности добавляются опционально.
Для команд, которые активно используют переиспользуемые workflow, особенно в монорепозиториях или при мульти-репозиторной архитектуре, это снижает необходимость в ручной передаче идентификаторов через inputs.
Что это значит для разработчиков
Все три обновления направлены на повышение предсказуемости и безопасности CI/CD-пайплайнов. REST API для раннеров позволяет автоматизировать мониторинг версий, vulnerability-alerts — снизить риски при работе с уязвимостями, а новые свойства job context — упростить отладку и логику переиспользуемых workflow.
Для команд, которые управляют большим количеством репозиториев или используют Actions в регулируемых средах, эти изменения особенно полезны. Они не требуют немедленного вмешательства, но дают инструменты для более тонкого контроля.
Источник: GitHub Changelog — GitHub Actions: Early September 2026 updates (https://github.blog/changelog/2026-09-03-github-actions-early-september-2026-updates)