События и триггеры: что запускает workflow и ловушка pull_request_target

Блок on: — это вся точка входа

Workflow не делает ничего, пока событие не совпадёт с его блоком on:. Есть три широких семейства событий, и различие управляет и поведением, и безопасностью:

on:
  push:
    branches: [main, "release/**"]
    paths-ignore: ["docs/**"]
  pull_request:
    types: [opened, synchronize, reopened]
  schedule:
    - cron: "17 3 * * 1-5"   # 03:17 UTC, пн–пт — смещение, чтобы уйти от давки на верху часа
  workflow_dispatch:          # вручную, с типизированными inputs
  workflow_call:              # вызывается как reusable workflow из другого

Фильтры комбинируются AND между ключами, OR внутри списка: branches: [main] и paths: [src/**] оба должны выполниться, но любая ветка из списка подходит. paths и paths-ignore взаимоисключающи на одном событии; смешение положительных и отрицательных глобов в одном списке paths — обычный источник «почему мой workflow не запустился». Тонкость, которая кусает команды с required-проверками: если фильтр paths пропускает workflow, required-проверка отчитывается как skipped, а не passed — и правило защиты ветки, требующее её, заблокирует мерж навсегда, пока вы не сделаете проверку сквозной. schedule cron только в UTC и работает по best-effort (по возможности, без гарантии): GitHub явно отбрасывает запланированные запуски под нагрузкой, и запуски на верху часа отбрасываются и задерживаются чаще всего — потому продакшн-расписания используют смещение вроде 17 3.

pull_request против pull_request_target — развилка безопасности

Для PR из форка pull_request выполняет workflow из head-ref PR, в песочнице с read-only GITHUB_TOKEN и без доступа к секретам. Это безопасный дефолт: недоверенный код выполняется, но не дотянется ни до чего ценного. pull_request_target выполняет workflow из базовой ветки (то есть файл workflow доверенный), но в контексте базового репозитория с полными секретами и read-write токеном — при этом код форка — это то, что выгрузится, если наивно сделать actions/checkout head PR. Эта комбинация и есть вектор эксфильтрации из Hook: доверенный триггер, недоверенный код, живые секреты.

# ОПАСНО: секреты в зоне видимости, затем выгружается и выполняется код форка
on: pull_request_target
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # ← код атакующего
      - run: npm ci && npm test   # ← выполняется с NPM_TOKEN в env

Эвристика: используй pull_request_target только для доверенной работы, которая никогда не выполняет код форка (повесить label, оставить комментарий, прогнать проверку, читающую метаданные). В момент, когда нужно собрать или протестировать реальный код контрибьютора, используй pull_request и прими, что секреты недоступны — либо закрой привилегированный шаг за environment с ручным одобрением.

Concurrency: отмени устаревший запуск, пока он не сжёг раннер

Каждая оживлённая PR-ветка теряет минуты раннеров на запуски, которые будут обогнаны до окончания — и без политики concurrency ты платишь за каждый. Спроси себя: есть ли что-то полезное в прогоне CI-сьюта против коммита, обогнанного сорок секунд назад?

Когда контрибьютор пушит три коммита за пять минут, три запуска становятся в очередь. Без управления concurrency все три выполнятся, а первые два устаревают в момент старта третьего. Блок concurrency это чинит:

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

cancel-in-progress: true отменяет любой выполняющийся запуск той же группы при старте нового — канонический PR-паттерн, с ключом по github.ref, чтобы каждая ветка была своей группой. Это регулярно срезает большую долю впустую потраченных минут на оживлённых ветках. Обратный паттерн тоже важен: для deploy-workflow нужен cancel-in-progress: false, чтобы деплой никогда не убивался на полпути, а группа сериализовала деплои по одному за раз. Когда добавляешь concurrency к deploy-workflow и второй деплой стартует на полпути первого — сначала реши, какой провал хуже: наполовину задеплоенное окружение или деплой в очереди, который просто ждёт. Concurrency — это гейт очереди, а не триггер: событие всё равно срабатывает; concurrency лишь решает, какие запуски выживут.