Skip to content

ci(release): add develop→main Release-PR automation#135

Merged
themightychris merged 4 commits into
mainfrom
feat/release-flow
Jun 26, 2026
Merged

ci(release): add develop→main Release-PR automation#135
themightychris merged 4 commits into
mainfrom
feat/release-flow

Conversation

@themightychris

Copy link
Copy Markdown
Member

Why

Stand up the Jarvus develop→main Release-PR flow so versioned releases are cut from a changelog'd PR, and the GHCR image build (currently a manual docker build/push) is automated on tag.

What

Four workflows + a ci.yml trigger update + operator docs:

Workflow Trigger Does
release-prepare.yml push to develop opens/updates a Release: vX.Y.Z PR into main with a bot changelog (GITHUB_TOKEN)
release-validate.yml the Release PR changes keeps title/version/changelog well-formed (GITHUB_TOKEN)
release-publish.yml Release PR merged tags vX.Y.Z (BOT_GITHUB_TOKEN — required so the tag can trigger the next workflow)
container-publish.yml v* tag pushed builds + pushes ghcr.io/codeforphilly/codeforphilly-ng:vX.Y.Z + :latest
  • ci.yml now also runs on develop.
  • docs/operations/releases.md documents the flow.

Adapted from the jarvus-data-pipeline reference: single image (no sub-image/BigQuery), actions/checkout@v6 + docker/login-action@v3, no --platform (CI runners + cluster are both amd64). The infra-components actions use the standard unpinned channels/.../latest refs.

After merge — operator steps (not code)

  1. Create develop off main (I'll do this once this lands).
  2. Confirm BOT_GITHUB_TOKEN repo/org secret is present (set) — required for release-publish.
  3. GHCR package write for Actions — first container-publish run creates the package; grant the repo's Actions write access.
  4. Branch protection on main (recommended) — require PR + green CI.

First push to develop will propose v0.1.0 (no tags yet).

🤖 Generated with Claude Code

themightychris and others added 4 commits June 26, 2026 10:27
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adopt the Jarvus develop→main release flow. Pushing `develop` opens a
"Release: vX.Y.Z" PR into main with a bot changelog (release-prepare);
merging it tags vX.Y.Z (release-publish, via BOT_GITHUB_TOKEN so the tag can
trigger downstream), which fires container-publish to build + push the GHCR
image (:vX.Y.Z + :latest) — automating the previously-manual docker build.
release-validate keeps the Release PR well-formed. ci.yml now also runs on
develop.

Workflows adapted from the jarvus-data-pipeline reference: single image (no
sub-image/BigQuery), checkout@v6 + login-action@v3, no --platform (CI + cluster
are amd64).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Also clarify in releases.md that release-validate guards main (only Release
PRs target main; feature work goes to develop) — its failure on the bootstrap
PR is expected.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@themightychris themightychris merged commit eac2394 into main Jun 26, 2026
1 of 2 checks passed
@themightychris themightychris deleted the feat/release-flow branch June 26, 2026 14:37
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