Release

Release

Announce at start: "I'm using the release skill."

Usage

/​release omniclaude omnibase_core        # Release specific repos
/​release --all --bump patch              # All repos, patch bump
/​release --dry-run                       # Show plan, no changes
/​release --resume <run_id>               # Resume failed run
/​release --gate-attestation <token>      # Pre-issued gate token for audit trail

Execution

Step 1 — Parse arguments

• repos → space-separated repo names (default: full dependency graph)
• --bump → version bump level (default: inferred from conventional commits)
• --dry-run → show plan table, no writes
• --resume <run_id> → resume from failed phase
• --gate-attestation → pre-issued gate token for audit trail

Step 2 — Initialize node (contract verification)

onex run-node node_release \
  --input '{"repos": [], "bump": null, "dry_run": false, "autonomous": false}' \
  --timeout 300

On non-zero exit, a SkillRoutingError JSON envelope is returned — surface it directly, do not produce prose. Note: handler is a structural placeholder; full migration tracked in OMN-8004.

Step 3 — Execute release phases

Processes repos in dependency-tier order (tier 0 → tier N):

1. GATE: Validate gate attestation (if provided) or proceed automatically
2. BUMP: For each repo — infer or apply version bump; update pyproject.toml + __version__
3. PIN: Update cross-repo dependency pins in downstream repos
4. PR: Create release PR per repo via gh pr create; enable auto-merge
5. MERGE: Wait for CI + merge queue; confirm merged
6. TAG: git tag v{version} + push; trigger PyPI publish workflow
7. WAIT: Poll PyPI for package availability (unless --skip-pypi-wait)
8. VERIFY: Confirm installed version matches released version

Step 4 — Report

Display release table: repo, old version, new version, PR, tag, PyPI status. Write ModelSkillResult to $ONEX_STATE_DIR/​skill-results/​{context_id}/​release.json.

Safety

• Proceeds automatically — no Slack approval gate
• --dry-run produces zero side effects: no bumps, PRs, tags, or PyPI triggers
• Resume support: state written after each phase; --resume <run_id> skips completed phases
• Cross-repo dependency pins use exact ==X.Y.Z format for determinism (exact pin policy)

Dependency Graph

Repos are released in dependency-tier order to guarantee downstream consumers get updated pins:

Tier N+1 repos pin the released version of Tier N repos. If a Tier 2 release fails, Tiers 3 through 6 are BLOCKED.

Error Table

ModelSkillResult

class ModelSkillResult:
    status: Literal["SUCCESS", "PARTIAL", "FAILED", "DRY_RUN"]
    repos_succeeded: list[str]
    repos_failed: list[str]
    run_id: str

Phase State Machine

Each repo progresses through this phase state machine independently:

PLANNED → WORKTREE → BUMPED → PINNED → CHANGELOG → LOCKED
       → LINT → COMMITTED → PUSHED → PR_CREATED → MERGED
       → TAGGED → PUBLISHED → DONE

Phases: PLANNED, WORKTREE, BUMPED, PINNED, CHANGELOG, LOCKED, LINT, COMMITTED, PUSHED, PR_CREATED, MERGED, TAGGED, PUBLISHED, DONE.

State is written atomically after each transition using a temp file + rename to guarantee crash-safe resume.

Idempotency

All mutations are deduplicated on resume:

Cross References

• merge-sweep: Used to verify merges succeeded and queues are clear
• pr-safety: Validates PR is mergeable (no conflicts, no blocking reviews)
• release.yml: GitHub Action triggered post-merge for PyPI publish
• auto-tag-reusable: Reusable workflow for git tag + push

Architecture

SKILL.md   -> thin shell (this file)
node       -> omnimarket/​src/​omnimarket/​nodes/​node_release/ (structural placeholder)
contract   -> node_release/​contract.yaml
migration  -> OMN-8004 (full handler implementation)