github-actions-efficiency

GitHub Actions Efficiency — официальный skill GitHub для аудита эффективности workflow и подготовки рекомендаций, которые уменьшают лишние CI-минуты и стоимость запусков. Это lean entrypoint: сначала нужно исследовать репозиторий и фактические запуски, а затем подгружать только тот справочный материал, который нужен для конкретного аудита. Если workflow ещё нет, skill предлагает начать с references/actions.md и определить базовую точку, а не строить оптимизацию на предположениях. Первый шаг — измерение. В локальном репозитории проверяются триггеры, concurrency, paths и paths-ignore, strategy и matrix, а также cache в .github/workflows. При доступном gh CLI нужно получить последние запуски через gh run list --limit 10, выбрать свежий run_id и посмотреть ошибки через gh run view --log-failed. Такой порядок помогает отличить проблему YAML от фактического поведения CI. В качестве основных источников потерь skill предлагает проверить отсутствие кэша зависимостей с ключом по lockfile, отсутствие отмены устаревших запусков, дублирующее покрытие workflow, слишком широкие триггеры и дорогие jobs, которые запускаются при любом изменении. После измерения выбираются не все возможные улучшения подряд, а максимум три, подтверждённые аудитом. Кандидаты включают lockfile-based dependency caching, concurrency cancellation, устранение дублирующего покрытия перед объединением jobs, безопасное сужение workflow- или job-триггеров, уменьшение matrix до явно обязательных версий и платформ, а также распараллеливание независимых jobs на критическом пути. Приоритет определяется ожидаемой экономией дневных CI-минут: экономия за запуск умножается на число запусков в день. Если кандидат не подтверждён данными или не проходит guardrail, его не следует включать только ради полноты отчёта. Guardrails защищают полезную проверку от слишком агрессивной оптимизации. Нельзя скрывать обязательную release-, schema-, migration- или shared-library валидацию. Нельзя уменьшать параллелизм без обоснования, особенно если критический путь станет длиннее чем примерно в 1,25 раза. Matrix-ноги удаляются только при отсутствии явной документированной поддержки версии или платформы. Write-back jobs, которые автоматически форматируют или изменяют репозиторий, нужно не молча удалять, а помечать и предлагать перевести на opt-in trigger. Настройки репозитория и организационные настройки GitHub должны рассматриваться раздельно. Финальный шаг — проверка. Если доступен gh CLI, path-gating и отмену concurrency нужно валидировать живым тестом push в нез защищённой ветке; косметического чтения YAML недостаточно. Если live-проверка невозможна, результат должен прямо разделять подтверждённое локально и непроверенное в GitHub. При отсутствии shell или gh CLI skill требует попросить содержимое .github/workflows и последние строки gh run list; отчёт в таком случае начинается с пометки Static-only analysis и явно указывает неполноту наблюдений. Отчёт должен содержать источники потерь, предлагаемые fixes, validation, остаточные риски и impact. В impact нужно разделять ожидаемую экономию от измеренной, а также wall-clock время pull request от суммарного runner time. Skill подходит для безопасного аудита кэшей, матриц, триггеров, отмены устаревших запусков и критического пути, но сам по себе не разрешает отключать обязательные проверки или выдавать статический анализ за доказанную экономию.