ci(workers): publish SHA-tagged workers image alongside :latest-workers

[therealbrad]

Description

Publishes a SHA-pinned workers image tag on every build so the k8s Deployment can stop pointing at the floating :latest-workers tag.

Background. On 2026-04-22, rollback of the multitenant-workers crashloop was effectively impossible: every revision in kubectl rollout history pointed at the same tag (:latest-workers), and the broken image had already overwritten the good one in GHCR. "Undo" had nowhere to roll back to.

What this PR does — in .github/workflows/release.yml:

• Derives SHORT_SHA=$(echo "${{ github.sha }}" | cut -c1-8) inside each build job.
• Adds one extra tag to the workers image in all 4 build jobs (tag-push + manual-dispatch, amd64 + arm64):
  • ghcr.io/testplanit/testplanit:workers-sha-<short-sha>-<arch>
• Adds a multi-arch manifest for the SHA tag in both merge jobs:
  • ghcr.io/testplanit/testplanit:workers-sha-<short-sha> (manifest list over amd64 + arm64)

Nothing is removed. :latest-workers and :${VERSION}-workers are still published and :latest-workers is still retagged by the existing "is this the newest semver" logic. This PR is purely additive.

What is NOT in this PR

The k8s Deployment manifest that references :latest-workers lives in the private-ops repo, not here (see the comment block in testplanit/k8s/multitenant-workers-rbac.yaml — it describes this split). A companion PR in private-ops is needed to change the Deployment's image: to :workers-sha-<short-sha>, parameterized per deploy.

Intermediate state while that PR is pending: this repo publishes the SHA tag but nothing consumes it yet. That's safe — the existing :latest-workers path is unchanged, so no behavior differs until ops flips the Deployment.

Related Issue

Follow-up to hotfix c804cac (workers crashloop 2026-04-22 16:30 UTC). Third of three post-mortem follow-ups:

• refactor(audit): split enqueue helpers out of auditContextWrappers #235 — split auditContextWrappers.ts so workers don't transitively import Next.js (root-cause fix).
• ci(workers): smoke-test worker image boots before promoting to :latest #237 — CI smoke test that boots each worker entrypoint (catches this class of bug pre-deploy).
• This PR — SHA-tagged workers images (gives ops a real rollback path when a bad image does ship anyway).

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Technically a CI/ops-infrastructure fix. No runtime code changes.

How Has This Been Tested?

• Unit tests
• Integration tests
• E2E tests
• Manual testing

The workflow file itself was validated:

• YAML parses cleanly (js-yaml load, six jobs present).
• All 4 build jobs set SHORT_SHA and add a workers-sha-${SHORT_SHA}-<arch> tag to the bake --set.
• Both merge jobs create a multi-arch manifest list for :workers-sha-${SHORT_SHA}.

The first real tag-push after this merges will publish the new tag as a side effect — that's the soonest a live run happens. The changes are additive and the tag-creation logic mirrors the established shape of the existing version/workers tags, so risk of breaking the current release path is low.

Test Configuration:

• N/A — workflow file change only.

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (inline in the workflow header)
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published
• I have signed the CLA

Additional Notes

Tag format choice. Short 8-char SHA (e.g., workers-sha-c804cace) matches the example in the post-mortem and the convention elsewhere in the project. Full 40-char SHAs are unambiguous but unwieldy as image tags.

Why workers only, not production. The 2026-04-22 incident was workers-specific and the user's post-mortem scoped this PR to workers. The production image has the same failure mode in principle (:latest is also floating), but extending the SHA-tag convention to production is a separate decision with its own deploy-flow implications. Happy to open a follow-up if ops wants it.

Rebase note. #237 also touches release.yml (adding smoke-test steps to the same build jobs). The two PRs are logically independent; whichever merges first, the second needs a trivial rebase — edits are in adjacent-but-not-overlapping blocks.

[therealbrad]

🎉 This PR is included in version 0.22.8 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀