Skip to content

Fold GitHub release steps into deploy.sh#50

Merged
RaoulSchaffranek merged 1 commit into
mainfrom
deploy-release-lifecycle
Jul 24, 2026
Merged

Fold GitHub release steps into deploy.sh#50
RaoulSchaffranek merged 1 commit into
mainfrom
deploy-release-lifecycle

Conversation

@RaoulSchaffranek

Copy link
Copy Markdown
Member

Why

PR #49 made scripts/deploy.sh the single source of truth for the cache and Docker deploy steps, but the GitHub-release lifecycle (draft → publish, plus failure cleanup) was still inlined as raw gh calls in release.yml and duplicated in the runbook. This folds those steps into the script too.

What

scripts/deploy.sh — three new subcommands wrapping the gh calls the workflow makes:

  • release-draftgh release create v<version> --draft --title … --target <REV>
  • release-cutgh release edit v<version> --draft=false
  • release-abortgh release delete v<version> --yes --cleanup-tag (best-effort; for the failure path)

They authenticate through gh itself (login or GH_TOKEN/GITHUB_TOKEN), so no secret is read directly. release-draft targets REV, which must be the deployed commit.

.github/workflows/release.ymldraft-release, cut-release, and both On failure, delete drafted release steps now call the script instead of inlining gh. Dropped the set -x from those steps (the script warns against tracing) and the unused make-release step output.

CONTRIBUTING.md — the runbook uses the new subcommands, and now states that a manual release must be built from a commit on main, since kup resolves komet-node versions against main (the gap that made a branch-built version invisible to kup list).

Verification

  • bash -n clean; --help renders the new subcommands.
  • Confirmed each subcommand's exact gh invocation by shadowing gh with a stub — they match the workflow's originals.
  • Not run against real GitHub from here (would create a release); the gh calls are argument-for-argument identical to the previous inline commands.

Add release-draft, release-cut, and release-abort subcommands so the
release lifecycle (draft the GitHub release, publish it, delete the
draft on failure) lives in the same single source of truth as the
cache and Docker deploy steps.

The Release workflow's draft-release, cut-release, and failure-cleanup
steps now call these subcommands instead of inlining gh, and the
CONTRIBUTING.md runbook uses them too. The runbook also now states that
a manual release must be built from a commit on main, since kup resolves
komet-node versions against main.
@RaoulSchaffranek
RaoulSchaffranek merged commit f590a69 into main Jul 24, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant