Composite-экшены: упаковка шагов без накладных расходов рантайма

Что такое composite-экшен на самом деле

Зачем вообще использовать composite, а не reusable workflow или скрипт? Потому что composite — единственный тип, не добавляющий никаких накладных рантайма: когда одиннадцать скопированных шагов становятся бременем поддержки, composite схлопывает их в одну строку uses: без контейнера и без Node-процесса. Вот как это работает изнутри.

Composite-экшен — это метаданные, а не программа. Его action.yml объявляет runs.using: "composite" и список steps, а в момент вызова GitHub Actions вклеивает эти шаги в вызывающую джобу так, будто вы написали их inline — они выполняются на том же раннере, в том же рабочем каталоге, под тем же $GITHUB_WORKSPACE. Нет процесса Node.js для запуска и нет образа контейнера для pull, так что накладные расходы быть экшеном — по сути парсинг YAML: однозначные миллисекунды против джобы, которая уже стоит секунды.

# .github/actions/setup-toolchain/action.yml
name: "Setup Toolchain"
description: "Install the toolchain, restore cache, authenticate"
inputs:
  version:
    description: "Toolchain version"
    required: false
    default: "20"
outputs:
  cache-hit:
    description: "Whether the dependency cache was restored"
    value: ${{ steps.cache.outputs.cache-hit }}
runs:
  using: "composite"
  steps:
    - uses: actions/setup-node@v4
      with:
        node-version: ${{ inputs.version }}
    - id: cache
      uses: actions/cache@v4
      with:
        path: node_modules
        key: deps-${{ hashFiles('package-lock.json') }}
    - name: Install
      shell: bash
      run: npm ci

Два правила кусают здесь старших авторов. Первое: каждый шаг run: внутри composite обязан объявить shell: — нет дефолта уровня джобы для наследования, так что голый блок run: проваливает валидацию. Второе: inputs — это не переменные окружения: внутри composite вы читаете их как ${{ inputs.version }}, а не $VERSION, и чтобы поднять значение к вызывающему, прокидываете его через outputs[].value, ссылающийся на output шага, как показывает проводка cache-hit выше.

Компромисс: скорость, купленная общим состоянием

То, что composite даёт бесплатно, — это же и то, что может ранить: отсутствие изоляции. Он выполняется в окружении вызывающего, видит его файлы и мутирует его файловую систему. Если ваш composite запускает npm install -g some-cli, этот бинарь теперь в PATH для каждого последующего шага джобы — удобно, пока два composite не поставят конфликтующие глобальные версии. Нет песочницы node_modules, нет вендоринга зависимостей; composite, зависящий от jq, предполагает, что jq уже есть на раннере. Это нормально для оркестрации — выстраивания инструментов, что у раннера уже есть, — и неверно для логики, нуждающейся в своих запиненных зависимостях. Этот последний случай — ровно то, для чего существуют JavaScript- и Docker-экшены.

Прежде чем ставить глобальный CLI внутри composite, спроси себя: ожидает ли следующий composite в этой джобе чистый PATH — или ему всё равно, что твой бинарь уже там? Этот вопрос вскрывает настоящую опасность до того, как она выстрелит в продакшне.

Ещё два острых края. Composite могут вкладываться и вызывать другие экшены, но обработка ошибок грубая: упавший шаг прерывает composite так же, как упавший шаг джобы прерывает джобу, и до 1.0 нельзя было даже использовать continue-on-error пошагово (теперь поддерживается, но условия if: на шагах composite всё ещё вычисляются иначе, чем на шагах воркфлоу — они не видят состояние success()/failure() уровня джобы так же). И пиннинг безопасности применяется рекурсивно: когда ваш composite делает uses: actions/cache@v4, этот тег изменяем. Для всего, что касается креденшелов, пиньте вложенные экшены полным commit SHA — uses: actions/cache@<40-символьный-sha> — чтобы скомпрометированный тег в зависимости не мог внедрить код в каждый воркфлоу, что вызывает ваш composite.