Release Management

RoboCo's gated release manager watches the company's own repository and proposes new versions for you to approve. It automates every step up to the decision, then stops and waits for your explicit approve or reject. Nothing publishes without you.

How the proposal works

A background loop runs the same deterministic readiness sweep a human would:

diff since the last tag
conventional-commit classification and semver bump suggestion
version-reference completeness
CHANGELOG completeness and a docs-drift check
migration single-head check
the quality gate's state

Once the change set clears a threshold and the gate is green, the manager opens one release proposal and holds it. The proposal is an ordinary task owned by the Secretary; it is never dispatched or started by anyone. It appears in the panel for you to approve or reject with changes.

Mermaid diagram source: flowchart TD A[Interval tick] --> B{Readiness sweep:<br/>commits · gate · docs · migrations} B -->|below threshold or red gate| A B -->|ready| C[Hold ONE release proposal for the CEO] C -->|reject| D[CANCELLED — frees the slot] C -->|approve| E[ReleaseExecutor: fail-closed] E --> F{Environment ladder set?} F -->|yes| G[Promote head→…→prod] F -->|no| H[Bump on default branch] G --> I[Version bumps + CHANGELOG] H --> I I --> J{Head rung CI verdict green?} J -->|no| K[Abort — nothing committed] J -->|yes| L[Commit + push chore release] L --> M{Release-commit CI green?} M -->|no| K M -->|yes| N[Publish via GitHub REST]

Fail-closed execution

When you approve, ReleaseExecutor:

Promotes the environment ladder, merging every rung above prod into the prod checkout — head→…→just-below-prod — before touching any version file. A ladderless project has nothing to promote.
Writes version bumps across the canonical file set (derived from the previous chore(release): commit).
Adds the CHANGELOG entry.
Verifies the head rung's CI verdict — it does not re-run the full quality gate inside the production container.
Aborts before committing anything if that verdict is red.
Commits chore(release): X.Y.Z and pushes.
Waits for that commit's own CI to go green.
Publishes the release through the GitHub REST API, not the gh CLI.

An already-published version is a no-op: approving twice never double-releases.

Release commit identity and signing

The release commit is authored as RoboCo Release Manager <release-manager@roboco.local> by default. You can override the committer identity:

bash

1ROBOCO_RELEASE_GIT_NAME=RoboCo Release Manager        # default2ROBOCO_RELEASE_GIT_EMAIL=release-manager@roboco.local # default3ROBOCO_RELEASE_SIGN_COMMITS=false                     # set true to GPG-sign

Curated CHANGELOG body

If the CHANGELOG contains a curated [Unreleased] section, the executor uses that body for the release entry and empties the section after stamping it into the new version. If no curated body is present, it falls back to the auto-generated conventional-commit summary.

Environment-ladder promotion

If RoboCo's own project has declared an environment ladder, the executor merges every rung above prod into the prod branch — head→…→just-below-prod — before bumping versions. Without a ladder, it behaves the same single-branch way as before. If any promotion merge conflicts, the release aborts before anything is committed.

Bounds and tuning

Variable	Default	Purpose
`ROBOCO_RELEASE_MANAGER_ENABLED`	`false`	Master switch. Even on, it only proposes.
`ROBOCO_RELEASE_MIN_COMMITS`	`8`	Minimum unreleased commits since the last tag before a release is proposed. A `feat` or `security` commit also qualifies on its own.
`ROBOCO_RELEASE_MANAGER_INTERVAL_SECONDS`	`3600`	Seconds between readiness assessment passes.

Enable it

Flip Settings → Feature Flags → "Gated release manager" (or set ROBOCO_RELEASE_MANAGER_ENABLED=true) and restart the backend. There is no per-project opt-in — it always targets RoboCo's own repository.

It never auto-publishes

The release manager only proposes. It never approves, merges, tags, or publishes on its own. Every release waits for your explicit decision.

→ Autonomous Maintenance for the multi-repo CI-watch and dependency-update bot that share the same release-executor background · Environment Branches & EnvSync for the ladder the executor promotes · Deploy for the host release pipeline and Makefile targets.

llms.txt