XGen Release Tool

XGen Release Tool is a keyboard-driven terminal dashboard for the two
GitHub Actions pipelines behind a component deploy API: release (build
images, tag, publish) and deploy (roll an environment to a released
version). It has the same panels-and-shortcuts feel as btop.

Highlights

• Release and deploy in one screen. Press m to switch modes. A

release is one per repo (no environment); a deploy targets development,
staging or production (d / s / p).

• Profiles. Frontend and backend are managed separately. Each has its

own ref, version and parameters per environment, plus a release block.
Every edit shows a live preview of the exact request.

• Stops a dangerous duplicate release. The release workflow pushes

images before it creates the git tag. Re-releasing an existing version
would overwrite those images and then fail. The version field turns red
when the tag already exists, and the release is blocked.

• Checks before anything is sent. Missing branches, unknown services

and releases already in progress are blocked. You're warned about a
version that isn't newer, a branch with no new commits, a partial release
whose deploys would fail, or deploying a version that was never released.

• Confirm with a full summary. Releases ask you to type the version;

production deploys ask you to type production.

• Release, then deploy. n suggests the next version after the latest

GitHub release. When the release succeeds, P puts that version into the
deploy form.

• Live run tracking. Each dispatch is matched to its GitHub Actions run,

with status and per-job results. If a release pushed images but failed to
tag, the run is flagged as a mismatch.

• Sessions renew themselves. Paste your Cognito refresh token once (the

DevTools curl or response JSON works too). The tool renews the 1-hour id
token before it expires or when the API returns 401, and asks again only
when the refresh token itself expires.

Design decisions

• Nothing runs without an explicit confirm. Anything that can't be undone

(a git tag, a GitHub Release, a production rollout) needs a typed
confirmation.

• Checks come from how the workflows really behave, not generic rules.
• If a check can't reach GitHub, it becomes a warning rather than silently

passing.

• Credentials stay on your machine: tokens are saved with 0600 permissions

in the snap's own data folder. Access tokens are refused, because the API
needs the id token.

• Config, token and run history live in

~/snap/xgen-release-tool/common/, so they survive snap updates.
Press o to edit the config in nano from inside the app.

Snap note: strict confinement can't run the gh CLI. In the snap, the
tag and branch checks become warnings and run status comes from the API
endpoint. Install the tool with uv tool install for full GitHub checks.

Press ? inside the app for every keyboard shortcut.