Automate release publishing on main

[jmcte]

Summary

• run the release image workflow automatically on pushes to main
• create the matching GitHub Release/tag after automatic image verification succeeds
• update README release publishing docs for the automatic path

Validation

• actionlint .github/workflows/release-image.yml
• ruby -e 'require "yaml"; YAML.load_file(".github/workflows/release-image.yml"); puts "release-image.yml parses"'
• git diff --check -- .github/workflows/release-image.yml README.md

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d8e4d1fac6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[athena-omt]

Thanks — the overall direction makes sense, and the workflow/test updates are scoped. I found one substantive blocker before this is safe to merge.

The new automatic push path still runs ./scripts/build-image.sh ... --push before the workflow checks whether v<version> already exists. On any later push to main that does not bump package.json / config.image.tag, the workflow will rebuild and push the same GHCR tag first, then the release step will notice the GitHub Release already exists and exit 0. That means an ordinary post-release main commit can silently replace the image behind an already-released version tag while reporting the automatic publish as already complete.

Please add an early guard for push-triggered runs before any image publish, e.g. compute release_tag then skip/fail the publish when that release already exists, or otherwise only auto-publish when the version/tag is new. The existing duplicate-release handling is too late because the mutable image tag has already been pushed by then.

Validation note: GitHub checks for the PR are green. Local validation was limited by the worker image missing actionlint, ruby, and installed node dependencies, but the issue above is visible from direct workflow inspection.

[jmcte]

@athena-omt addressed the blocker. The push-triggered path now checks for the matching GitHub Release immediately after computing release metadata and before any image build/push. If the release already exists, the automatic run fails before mutating the GHCR tag. I also updated the workflow contract test to assert that this guard exists and runs before ./scripts/build-image.sh --push, and corrected the README wording to match the new behavior.

Local validation:

• actionlint .github/workflows/release-image.yml
• pnpm vitest run test/release-workflow.test.ts
• git diff --check -- .github/workflows/release-image.yml test/release-workflow.test.ts README.md

[athena-omt]

Thanks — I re-reviewed the current branch and the previous blocker is addressed. The push-triggered duplicate-release guard now runs immediately after release_meta and before ./scripts/build-image.sh ... --push, so an existing release for the configured version will fail before mutating the GHCR image tag.

The workflow/test/README changes are scoped, and the live PR checks are green. Local validation on the Athena worker was limited by missing ruby, actionlint, and installed node dependencies, but git diff --check passed for the changed files and the ordering/assertion added in test/release-workflow.test.ts covers the important regression path.

Approved from my side.