Автоматизация в GitHub

Enterprise policies и migration

Enterprise policies в GitHub Actions — это слой управления выше отдельных .github/workflows/*.yml: кто вообще может запускать Actions, какие actions разрешены, как долго хранить logs и artifacts, какие workflows обязательны перед merge и как мигрировать легаси CI без хаотичного ручного переписывания. В маленьком репозитории это выглядит как «настройки CI». В enterprise-контексте это уже supply chain governance: стандартные guardrails для десятков или тысяч репозиториев.

Эта тема связывает Secure use и threat model, Marketplace actions и pinning, Reusable workflows, Runner governance, Monitoring и troubleshooting, Artifacts и reports и Deployment workflows.

Уровни управления: enterprise, organization, repository

GitHub Actions policies можно задавать на разных уровнях. Enterprise owner может включить Actions для всех organizations, только для выбранных organizations или отключить их полностью. Ниже organization и repository owners могут иметь собственные настройки, если enterprise policy не зафиксировала поведение сверху.

Главный принцип: enterprise policy задаёт «коридор», а workflow-файл внутри репозитория всё равно должен быть написан безопасно. Например, можно запретить непроверенные third-party actions, но это не спасёт workflow, который печатает secrets в logs или делает опасный pull_request_target checkout. Поэтому policies дополняют Permissions и GITHUB_TOKEN, pull_request_target и untrusted PR и OIDC и секреты облаков, а не заменяют их.

Allowed actions: allowlist вместо «всё из Marketplace»

Для supply chain контроля GitHub позволяет ограничивать, какие actions и reusable workflows можно использовать. Типичные режимы:

• разрешить все actions и reusable workflows;
• разрешить только actions/reusable workflows из enterprise;
• разрешить enterprise-внутренние плюс выбранные внешние;
• требовать pinning actions к full-length commit SHA.

Практический enterprise-паттерн — не пытаться сразу запретить всё, а начать с наблюдения: какие uses: реально встречаются в репозиториях, какие из них critical path для CI/CD, какие принадлежат GitHub, какие — verified creators, какие — случайные abandoned repositories. После этого вводят allowlist.

Пример policy-мышления, не YAML GitHub UI, а инвентарная модель:

Всегда разрешить:
  actions/checkout@<full-sha>
  actions/setup-node@<full-sha>
  github/codeql-action/*@<full-sha>

Разрешить внутренние:
  my-enterprise/*@*
  my-platform/.github/.github/workflows/*@v*

Запретить явно:
  untrusted-org/*@*

Важно: SHA pinning сильнее, чем tag pinning, потому что tag можно переместить. Но у SHA pinning есть эксплуатационная цена: обновления нужно вести через Dependabot, renovate-подобный процесс или централизованные reusable workflows. Иначе enterprise «застынет» на старых actions.

Workflow templates: стандарты как стартовая точка

Workflow templates помогают командам быстро создать правильный CI workflow. В organization обычно заводят репозиторий .github, внутри него — директорию workflow-templates, а рядом с каждым template-файлом кладут metadata-файл .properties.json.

Минимальный пример template:

# .github/workflow-templates/node-ci.yml
name: Node CI

on:
  push:
    branches: [$default-branch]
  pull_request:
    branches: [$default-branch]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

{
  "name": "Node CI",
  "description": "Стандартный CI для Node.js проектов организации.",
  "iconName": "octicon check-circle",
  "categories": ["JavaScript", "TypeScript"],
  "filePatterns": ["package.json$"]
}

$default-branch заменяется на default branch конкретного репозитория при создании workflow. Это удобно, потому что в одной организации могут жить main, master, develop и исторические branch names.

Но template — это подсказка, а не enforcement. Если нужно именно требовать стандартный check перед merge, нужен ruleset workflow.

Required workflows через rulesets

В GitHub Enterprise Cloud workflows можно требовать через repository rulesets: PR нельзя merge, пока указанный workflow не прошёл. Это ближе к policy, чем workflow template. Хороший required workflow проверяет то, что должно быть одинаковым для всех: базовый security lint, проверку pinning, license policy, минимальный CodeQL или внутренний compliance gate.

Пример required workflow лучше держать простым:

name: Required CI Guardrail

on:
  pull_request:
  merge_group:

permissions:
  contents: read

jobs:
  guardrail:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
      - name: Check workflow policy
        run: ./scripts/check-actions-policy.sh

У ruleset workflows есть важная деталь: поддерживаются pull_request, pull_request_target и merge_group, а filters вроде branches, paths, types для этих events игнорируются. Поэтому не надо проектировать required workflow так, будто paths: спасёт от лишних запусков. И не применяйте такой ruleset ко всем branches: required workflow работает в PR/merge queue сценарии и может блокировать direct pushes.

Если нужен privileged automation, не смешивайте его с required validation. Validation должен быть read-only; privileged действия лучше выносить в отдельный workflow с environments, approvals и узким permissions.

Retention: logs и artifacts как compliance-объекты

По умолчанию workflow artifacts и logs хранятся 90 дней. Organization может изменить retention: для public repositories — от 1 до 90 дней, для private repositories — от 1 до 400 дней. Enterprise или управляющая organization может поставить верхний предел, а изменение применяется только к новым logs/artifacts, не задним числом.

Это не только вопрос стоимости. В Artifacts и reports artifacts часто содержат test reports, screenshots, traces, build outputs и deployment manifests. Иногда там случайно оказываются internal URLs, generated configs или фрагменты чувствительных данных. Поэтому retention policy должна быть разной для разных классов данных: короткая для debug dumps, дольше для release evidence, отдельно для compliance artifacts.

На уровне workflow можно дополнительно задать retention для конкретного artifact:

- uses: actions/upload-artifact@v4
  with:
    name: playwright-trace
    path: test-results/
    retention-days: 7

Audit: кто поменял правила и что удалил

Enterprise audit log — источник фактов для governance. В нём есть events по enterprise/org/repo activity, API requests, если в настройках audit log включены API Request Events (такие events доступны только через audit log streaming), cache deletion, artifact deletion и категориям, связанным с workflows. Для расследований это дополняет Monitoring и troubleshooting: run logs говорят, что произошло внутри job, audit log говорит, кто изменил правила вокруг job.

На практике полезно смотреть не только failed runs, но и изменения вокруг них:

# пример направления, не универсальная готовая команда для всех enterprise
# ищите по actor, repo, org, action category и временному окну инцидента
policy changed at 10:12
workflow failed at 10:16
artifact manually deleted at 10:20

Если organization использует SIEM, audit log streaming становится частью нормальной security telemetry: кто изменил Actions policy, кто удалил artifact, кто поменял repository ruleset, какой token сделал API-запрос.

GitHub Actions Importer: migration без иллюзии «автопереводчика»

GitHub Actions Importer помогает планировать и автоматизировать миграцию CI/CD pipelines из Azure DevOps, Bamboo, Bitbucket Pipelines, CircleCI, GitLab, Jenkins и Travis CI. Он распространяется как Docker container и вызывается через GitHub CLI extension.

Базовый flow:

gh extension install github/gh-actions-importer
gh actions-importer configure

gh actions-importer audit jenkins
gh actions-importer forecast jenkins
gh actions-importer dry-run jenkins
gh actions-importer migrate jenkins

Смысл команд разный. audit даёт картину текущего CI footprint. forecast помогает оценить будущий usage GitHub Actions. dry-run генерирует workflow locally для ревью. migrate создаёт pull request с converted workflow.

Ключевой факт: converted workflow нужно ревьюить перед production. GitHub прямо предупреждает, что цель — около 80% conversion rate для workflow, но реальный результат зависит от конкретного pipeline. Jenkins shared libraries, нестандартные shell scripts, custom Docker images, credentials binding, deploy approvals и ручные gates почти всегда требуют человеческого решения.

Хорошая migration sequence выглядит так:

1. Инвентаризировать pipelines и owners.

2. Выбрать 2–3 pilot repositories разной сложности.

3. Сначала перенести CI, потом release/deploy.

4. Заменить долгоживущие cloud credentials на Cloud deploy через OIDC, где возможно.

5. Вынести повторяющиеся паттерны в Reusable workflows или Composite actions.

6. Включать policies постепенно: templates → allowlist → SHA pinning → required workflows.

7. Сравнить старые и новые метрики: duration, failure rate, queue time, retry rate.

Главная ошибка migration — механически переписать YAML и сохранить старую архитектуру. GitHub Actions лучше работает, когда pipeline использует native primitives: needs, matrix, artifacts, environments, OIDC, reusable workflows и repository rulesets.

See also

• Marketplace actions и pinning — как выбирать и закреплять third-party actions.
• Reusable workflows — стандартизация целых jobs и pipelines.
• Composite actions — переиспользование набора steps.
• Permissions и GITHUB_TOKEN — минимальные права workflow token.
• pull_request_target и untrusted PR — почему privileged PR automation опасна.
• Runner governance — runner groups, labels, isolation и network access.
• Monitoring и troubleshooting — run history, logs, API и operational metrics.
• Artifacts и reports — что хранить как artifact и как выбирать retention.
• Cloud deploy через OIDC — migration path away from static cloud secrets.

Внешние справки: GitHub Docs по enterprise Actions policies, workflow templates, ruleset required workflows, artifact/log retention, audit log events, secure use reference и GitHub Actions Importer.