forge-public/cloud@v2

Единственный reusable-workflow конвейера доставки: заменяет пару server-publish@v1 + cloud-render@v1. Здесь лежит только .forgejo/workflows/deploy.yml — сам инструмент не здесь, он приезжает npm-пакетом @rolder/cloud из реестра кузни. Источник правды на инструмент — talos/k8s/cloud-tool/ в репозитории облака.

Править файлы в этом репозитории бесполезно: плей M100 --tags cloud-deploy перезапишет их при следующем прогоне — этот репозиторий генерируется, а не редактируется руками.

Использование

Caller у потребителя — константа, одинаковая во всех репозиториях:

on: { push: { branches: ['deploy/**'] }, workflow_dispatch: {} }
jobs:
  deploy:
    uses: forge-public/cloud/.forgejo/workflows/deploy.yml@v2
    secrets: inherit

Как получить инструмент

В проекте — так. Скоуп в .npmrc РЕПОЗИТОРИЯ, пакет в devDependencies:

echo '@rolder:registry=https://git.rolder.cloud/api/packages/forge-public/npm/' >> .npmrc
bun add -d @rolder/cloud
bunx cloud check

Тогда версия пинится локфайлом, скоуп едет вместе с репозиторием, а bunx cloud резолвится из локального node_modules/.bin и в реестр на запуске не ходит вовсе.

Так, без флагов, check хосты не сверяет вовсе (#688): передай --branch deploy/<среда> (правило хоста смотрит только на деплой этой ветки), для правила корня платформы rolder.cloud — --apex <апекс тенанта>, и для правила занятости — --taken '<CLOUD_HOSTS>' (книга имён, занятых другими тенантами; её пишет реконсилер в переменную организации CLOUD_HOSTS, локально берётся оттуда же) — все три флага подаёт сам deploy-workflow в CI, локально их нужно передать руками.

Разово, без установки — только через bun x, и обязательно им, а не bunx:

bun x --bun @rolder/cloud@<версия> check --branch deploy/<среда> --apex <апекс тенанта> --taken '<CLOUD_HOSTS>'

Хост без --branch не проверяется, как и выше; --apex нужен только для правила корня rolder.cloud, --taken — для правила занятости (пустая книга у деплойного репозитория — отказ, как и пустой апекс; паблишеру ни то, ни другое не нужно).

Почему именно bun x: bunx в системе может оказаться ДРУГОЙ, отстающей сборкой bun, чем bun (замер 2026-09-02: bunx из nix-профиля 1.3.13 скоуп не читает и уходит на npmjs с 404, bun x из ~/.bun 1.4.0 читает). Скоуп для этой формы работает только в $HOME/.npmrc: bun x исполняется из своего временного каталога и файлов проекта не видит. ~/.bunfig.toml не работает вовсе — если где-то остался такой совет, он неверен.

Контракт

Справочник полей декларации cloud.yaml печатает сам инструмент — файла с ним нет ни здесь, ни в репозитории потребителя, ни в скиле:

bunx cloud reference                        # весь контракт: форма, уровни, поля
bunx cloud reference --kind server --json   # для агента

Раздел «Форма» отвечает на вопрос, которого нет в списке полей: инстанс лежит под именем вида, среды — под инстансом, и часть полей (origin, env, secrets) стоит у инстанса, а не у среды.

Без версии bunx берёт latest — а latest и то, что гоняет @v2, это одна и та же публикация: плей M100 --tags cloud-deploy публикует пакет и двигает тег v2 одним прогоном и отказывается публиковать рассинхрон. Значит локальная проверка и CI смотрят на один контракт.