Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

ferrogate-release

Sterne20

Forks4

Aktualisiert19. Juli 2026 um 06:36

Use when cutting a FerroGate release — building the container image and publishing it to GHCR. Covers the standing directive to NOT use GitHub Actions (too slow) and instead gate on the local ferrogate-test suite then push locally, including the no-sudo/no-Docker host path (musl-static + crane). Use for "release", "publish image", "push to GHCR", "cut a version".

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

lianluo-esign

lianluo-esign/ferrogate

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	ferrogate-release
description	Use when cutting a FerroGate release — building the container image and publishing it to GHCR. Covers the standing directive to NOT use GitHub Actions (too slow) and instead gate on the local ferrogate-test suite then push locally, including the no-sudo/no-Docker host path (musl-static + crane). Use for "release", "publish image", "push to GHCR", "cut a version".

FerroGate Release

Standing directive (2026-07-19): do NOT release through GitHub Actions. The GitHub-hosted ci.yml / ci-image.yml release pipeline is too slow (15+ min, one serial failure per run) and blocks dev velocity. Instead:

local ferrogate-test full suite green → build image locally → push straight to GHCR.

Gate first (non-negotiable)

Never build/push an image until the local gate is green:

source $HOME/.local/tcbin/rust-env.sh
cargo +1.88.0 fmt --check
cargo +1.88.0 clippy --workspace --all-targets --all-features -- -D warnings
cargo +1.88.0 test --workspace
cargo +1.88.0 build --release -p ferrogate-test && ./target/release/ferrogate-test ci

On the ~6 GB dev box a full-workspace test/clippy link can OOM — scope to the crates you touched (-p ...) when iterating; run the full suite for the actual release gate. See the ferrogate-test / ferrogate-test-strategy skills.

Build + push

One entry point, auto-detects the engine:

scripts/release-local.sh --tag vYYYY.MM.DD --push          # full gate + build + push
scripts/release-local.sh --tag vYYYY.MM.DD                 # dry-run (no push)
scripts/release-local.sh --tag vYYYY.MM.DD --skip-tests --push   # image only (gate already run)

Host has Docker → uses the reference Dockerfile (glibc, builds in rust:bookworm).
No Docker / no sudo → falls back to scripts/build-image-crane.sh: a fully static musl binary packaged into an OCI image with crane — no daemon, no root, no namespaces. This is the path on the locked-down dev host. Full setup and rationale: docs/release/local-image-build.md.

The credential gate

GHCR push needs a token with write:packages. The dev-host gh login lacks it (only repo/workflow/project/read:org/gist). Supply one of:

export GHCR_TOKEN=<classic PAT with write:packages>, or
gh auth refresh -s write:packages (interactive) then re-run.

Without it, --push fails fast; the dry-run still fully validates build + assembly.

Supply-chain trade-off (#208)

Local signing uses your own key, not the GitHub-workflow keyless OIDC identity, so scripts/verify-image-supply-chain.sh --mode release (pinned to the CI workflow identity) will reject a locally-built image by design. That is the accepted price of skipping GitHub CI. If keyless workflow provenance is ever mandatory, run ci-image.yml on a self-hosted runner — never fabricate provenance.

Checklist

Local gate green (fmt + clippy + workspace tests + ferrogate-test ci).
Pick --tag vYYYY.MM.DD (date-based).
Dry-run first; confirm image config (entrypoint /usr/local/bin/ferrogate run, EXPOSE 8080, FERROGATE_CONFIG).
Ensure a write:packages token; --push.
Verify the published digest (crane digest ghcr.io/<owner>/ferrogate:<tag>).
Do NOT cut a GitHub Release for routine releases.

Mehr aus diesem Repository

gleiches Repository

ferrogate-code-review

lianluo-esign/ferrogate

Use when running the FerroGate code-review role of the three-agent board loop — the session that watches the GitHub Project "In review" lane, judges what the dev agent handed off, and either advances the item to "Testing" or bounces it back to "Ready" with findings (e.g. "run the review agent", "work the In review lane", "review what the dev loop landed"). Covers the fixed lane/edges, the board handles, the review methodology (acceptance-box audit first, static verification over rebuild, report-never-edit, `review-rejected` on bounce), and the shared discipline (GraphQL quota rationing, cached lane tooling, worktree isolation, never build in the main worktree). Neighbouring roles: ferrogate-dev-loop (upstream) and ferrogate-test (downstream); all three at once: ferrogate-multi-agent-loop.

2026-07-2520

ferrogate-test

lianluo-esign/ferrogate

Use when working in the FerroGate repo and the task involves the ferrogate-test Rust CLI itself — running Admin API or gateway API E2E coverage, CI harness verification, Docker-backed cluster scenarios, editing tools/ferrogate-test, or release-grade end-to-end validation. For deciding which test layer a change needs and how findings become issues, use the ferrogate-test-strategy skill.

2026-07-2520

ferrogate-multi-agent-loop

lianluo-esign/ferrogate

Use when running FerroGate development as THREE cooperating autonomous agents — a code-generation-only dev driver that fans slices out across worktree-isolated subagents, a code-review agent, and a test gate — coordinating through the GitHub Project board (e.g. "run the dev loop, the review and the test gate", "keep the board moving with all three agents", setting up the dev/review/test split, or checking what a neighbouring role will do with your output). Covers the choreography, the board handoff (Ready → In progress → In review → Testing → Done, with every failure bouncing back to Ready), the seven Status option IDs, and the shared GraphQL quota discipline. For one role only, use ferrogate-dev-loop (dev), ferrogate-code-review (review), or ferrogate-test / ferrogate-test-strategy (gate).

2026-07-2520

ferrogate-dev-loop

lianluo-esign/ferrogate

Use when running FerroGate development as an autonomous, continuously-iterating code-generation loop that fans work out across parallel subagents against the GitHub Project board (e.g. "keep iterating on the board", "持续迭代开发", a /loop that advances issues). This is the DEV role of the three-agent loop — code generation only. Covers the binding constraints — advance sub-issues only up to "In review" (never Testing, never Done), Ready is also the rework inbox for bounced issues, Projects GraphQL quota discipline, the max-3 parallel-subagent ceiling, worktree isolation + slice separation, the cherry-pick integration flow, and mandatory worktree cleanup to bound disk. For the neighbouring roles see ferrogate-code-review and ferrogate-test; for all three at once see ferrogate-multi-agent-loop. Not for a single named-issue slice (use docs/dynamic-workflow.md).

2026-07-2520

ferrogate-test-strategy

lianluo-esign/ferrogate

Use when working in the FerroGate repo and deciding how to test a change — which test layer a change needs, adding coverage for a feature or bugfix, whether the harness is sufficient, or when a test run surfaces a bug or new feature that needs tracking. For running the harness CLI itself, use the ferrogate-test skill.

2026-07-1320

name	ferrogate-release
description	Use when cutting a FerroGate release — building the container image and publishing it to GHCR. Covers the standing directive to NOT use GitHub Actions (too slow) and instead gate on the local ferrogate-test suite then push locally, including the no-sudo/no-Docker host path (musl-static + crane). Use for "release", "publish image", "push to GHCR", "cut a version".

FerroGate Release

local ferrogate-test full suite green → build image locally → push straight to GHCR.

Gate first (non-negotiable)

Never build/push an image until the local gate is green:

source $HOME/.local/tcbin/rust-env.sh
cargo +1.88.0 fmt --check
cargo +1.88.0 clippy --workspace --all-targets --all-features -- -D warnings
cargo +1.88.0 test --workspace
cargo +1.88.0 build --release -p ferrogate-test && ./target/release/ferrogate-test ci

Build + push

One entry point, auto-detects the engine:

scripts/release-local.sh --tag vYYYY.MM.DD --push          # full gate + build + push
scripts/release-local.sh --tag vYYYY.MM.DD                 # dry-run (no push)
scripts/release-local.sh --tag vYYYY.MM.DD --skip-tests --push   # image only (gate already run)

Host has Docker → uses the reference Dockerfile (glibc, builds in rust:bookworm).
No Docker / no sudo → falls back to scripts/build-image-crane.sh: a fully static musl binary packaged into an OCI image with crane — no daemon, no root, no namespaces. This is the path on the locked-down dev host. Full setup and rationale: docs/release/local-image-build.md.

The credential gate

GHCR push needs a token with write:packages. The dev-host gh login lacks it (only repo/workflow/project/read:org/gist). Supply one of:

export GHCR_TOKEN=<classic PAT with write:packages>, or
gh auth refresh -s write:packages (interactive) then re-run.

Without it, --push fails fast; the dry-run still fully validates build + assembly.

Supply-chain trade-off (#208)

Checklist

Local gate green (fmt + clippy + workspace tests + ferrogate-test ci).
Pick --tag vYYYY.MM.DD (date-based).
Dry-run first; confirm image config (entrypoint /usr/local/bin/ferrogate run, EXPOSE 8080, FERROGATE_CONFIG).
Ensure a write:packages token; --push.
Verify the published digest (crane digest ghcr.io/<owner>/ferrogate:<tag>).
Do NOT cut a GitHub Release for routine releases.