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

Marketplace actions и pinning

Marketplace action — это готовый building block для steps[].uses: checkout, setup runtime, login в registry, upload reports, deploy, security scan. Технически GitHub Marketplace — только витрина. Workflow подключает не «карточку Marketplace», а репозиторий и ref в форме owner/repo[/path]@ref, поэтому тот же trust model работает и для action из README, и для action из внутреннего репозитория.

Ключевая мысль: action выполняется внутри job и получает тот же workspace, network, environment и права GITHUB_TOKEN, которые доступны job. Если job читает secrets, пушит image или получает cloud token через Cloud deploy через OIDC, сторонний action оказывается рядом с самым чувствительным местом pipeline. Поэтому выбор action — это не только вопрос удобства YAML, а часть Secure use и threat model.

Что именно вы подключаете

Запись uses состоит из трёх решений: чей код, какая точка входа и какой ref.

steps:
  - uses: owner/action-name@v3          # tag: удобно, но tag можно передвинуть
  - uses: owner/action-name@main        # branch: почти всегда слишком плавающий ref
  - uses: owner/action-name@0123456789abcdef0123456789abcdef01234567 # SHA: конкретный commit

Branch удобен для эксперимента, но плох для воспроизводимости: сегодня и завтра это может быть разный код. Major tag вроде @v3 даёт обновления без изменения workflow, но остаётся mutable ref. Полный commit SHA — единственный практический способ сказать: «запусти ровно тот код, который мы посмотрели». Для third-party actions в deploy, release, package publish и security-sensitive jobs это нормальный baseline, а не паранойя.

Tag всё ещё используют, особенно для first-party actions и низкорисковых CI steps. Но риск надо называть честно: если tag будет передвинут или репозиторий action скомпрометирован, workflow начнёт выполнять другой код без изменения вашего YAML. Badge «Verified creator» в Marketplace полезен как сигнал идентичности автора, но не превращает mutable tag в immutable release.

Как читать action.yml

Перед добавлением action откройте его action.yml или action.yaml. Это metadata-файл action: он объявляет inputs, outputs, runs и иногда branding. По runs.using сразу видно тип:

name: Example deploy action
inputs:
  token:
    description: GitHub token or service token
    required: true
  dry-run:
    description: Print commands without applying changes
    default: "false"
runs:
  using: node24
  main: dist/index.js

runs.using: node20 или node24 означает JavaScript actions. runs.using: composite ведёт к набору workflow steps (run и, при необходимости, uses) из Composite actions. runs.using: docker означает Docker container actions, которые дают контролируемое Linux-окружение, но добавляют build/pull latency и работают только на Linux runners.

inputs показывают, что action ждёт через with. Не ограничивайтесь README: README может устареть, metadata ближе к runtime-контракту. Важная деталь из GitHub Docs: required: true в metadata само по себе не гарантирует автоматическую ошибку при отсутствии input; хорошая action должна валидировать критичные inputs в своём коде.

Пример подключения с явным with и минимальными permissions:

name: publish-image

on:
  push:
    tags: ["v*"]

permissions:
  contents: read
  packages: write

jobs:
  publish:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v6

      - name: Login to GHCR
        uses: docker/login-action@0123456789abcdef0123456789abcdef01234567
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

Здесь SHA — пример формы pinning, не рекомендация конкретного commit. В реальном repo SHA берут из release/tag action и проверяют, что commit принадлежит исходному репозиторию, а не fork. Связь с Permissions и GITHUB_TOKEN прямая: даже хорошо pinned action не должен получать лишние права job.

Supply chain risk на практике

Плохой критерий выбора: «у action много stars, значит можно». Лучше смотреть на несколько сигналов сразу: кто maintainer, есть ли releases и changelog, как устроен action.yml, есть ли pinned dependencies, открыта ли security policy, насколько часто ломаются issues, есть ли понятная migration/deprecation policy. Для JavaScript action отдельно проверьте, что исполняемый dist/ действительно обновляется в release, потому что workflow запускает bundled code, а не TypeScript-исходники из соседней папки.

Риск зависит от job. Action, который форматирует Markdown в CI без secrets и с contents: read, опасен меньше. Action, который работает в Deployment workflows, публикует Packages и container images, получает id-token: write или запускается рядом с environment secrets, надо рассматривать как production dependency. Для pull request сценариев особенно осторожно сочетание стороннего action, checkout непроверенного кода и событий из pull_request_target и untrusted PR.

Dependabot updates

Pinning к SHA не должен превращать workflow в музей. GitHub поддерживает Dependabot version updates для ecosystem github-actions: бот смотрит workflow-файлы в .github/workflows и reusable workflows, затем открывает PR на обновление outdated refs.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      actions:
        patterns:
          - "*"

Dependabot PR — это повод для review, а не автоподпись под новым supply chain state. Для низкорискового CI можно включить auto-merge после зелёных checks. Для deploy/login/security actions лучше смотреть release notes, diff между старым и новым commit, изменения в action.yml, новые network/API permissions и открытые security advisories. Если updates шумят, группируйте их, но не отключайте полностью: старый action тоже становится риском, особенно когда runtime вроде Node устаревает.

Когда Marketplace action не нужен

Если action заменяет одну понятную shell-команду, иногда лучше оставить run. Если один и тот же набор steps повторяется в нескольких workflow внутри repo, часто лучше сделать Composite actions. Если нужно стандартизовать целый pipeline с jobs, permissions, environments и outputs между репозиториями, берите Reusable workflows. Marketplace action хорош там, где он реально покупает поддержку чужой интеграции: setup SDK, auth flow, upload report, deploy adapter, сложную работу с GitHub API.

Практическое правило: чем ближе action к secrets, release, deploy и write permissions, тем строже pinning, review и ownership. Внутри организации это часто оформляют policy: разрешённые owners, обязательный SHA pin, CODEOWNERS на .github/workflows, отдельный review для изменения deploy actions и регулярный аудит через Monitoring и troubleshooting и Enterprise policies и migration.

See also

• Permissions и GITHUB_TOKEN — как ограничить blast radius стороннего action через job-level permissions.
• Variables, env и secrets — что action может прочитать из окружения и почему secrets требуют аккуратности.
• Reusable workflows — когда переиспользовать не step, а целый job/pipeline.
• Composite actions — локальная альтернатива copy-paste steps и мелким Marketplace dependencies.
• JavaScript actions — как устроены Node-based actions и почему важен bundled dist/.
• Docker container actions — когда action нужен собственный Linux container.
• Versioning и maintenance actions — semantic tags, immutable releases, changelog и backward compatibility.
• Secure use и threat model — общий threat model для workflow, third-party code и secrets.

Внешние справки: GitHub Docs по secure use, metadata syntax, Dependabot updates for actions и release/maintenance actions.