Derive OCI publish mode from trigger for bunyip-api and bunyip-web #258
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/GOV-15-twin-trigger-publish-mode"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ports the GOV-13 twin-trigger publish-mode fix into bunyip's two OCI build workflows as part of the GOV-15 rollout. This is a multi-image repo, so both build-api.yml (bunyip-api) and build-web.yml (bunyip-web) are ported in this one branch, alongside their single shared oci-build/get-tags.nu helper.
The bug: both workflows trigger on push to BOTH branches: [main] and tags: [v*], and resolved their tag set from git describe via the shared oci-build/get-tags.nu --joined helper, which returned [vX.Y.Z, latest] on a tagged commit. A release commit is simultaneously a main push and a v* tag push, so both events fire, both build the same image, and both race to overwrite the mutable :latest tag (a 409 on immutable generic-package files and an overwrite race on the OCI latest tag).
The fix: derive the publish MODE from the trigger rather than git describe. A tag ref resolves the release train (publishes only :vX.Y.Z), a main push resolves the latest train (publishes only :latest), and a manual workflow_dispatch resolves a dry-run that builds locally and mutates neither the registry nor the gha cache. The two runs now write DISJOINT tag sets and never collide.
The shared oci-build/get-tags.nu helper is rewritten to take --mode (release|latest|dry-run) and return a { mode, train, tag, describe } record. Both workflows gain a workflow_dispatch dry_run / simulate_tag input, a "Resolve publish mode, train and tag" step, and dry-run-aware build-and-push and print-URL steps. Everything repo-specific is preserved unchanged: image names (bunyip-api / bunyip-web), the dev.a8n.run/psa-systems-private registry and secret wiring, the type=gha per-image cache scope (GOV-21), the GIT_COMMIT / GIT_TAG / BUILD_DATE / CARGO_BUILD_JOBS build-args, and the two Dockerfile paths.
Verification (all PASS): YAML parses for both workflows, nu-check true on the helper, the four functional modes resolve the right tag (release v9.9.9, latest, dry-run --simulate-tag v9.9.9 -> release v9.9.9, dry-run -> latest), and both error paths (bogus mode, release with no version) exit non-zero.
Both build-api.yml and build-web.yml triggered on push to BOTH branches: [main] and tags: [v*], and resolved their tag set from git describe via the shared oci-build/get-tags.nu --joined helper, which returned [vX.Y.Z, latest] on a tagged commit. A release commit is at once a main push and a v* tag push, so both events fired, both built the same image, and both raced to overwrite the mutable :latest tag (a 409 on immutable generic-package files, an overwrite race on the OCI latest tag). Derive the publish MODE from the trigger instead: a tag ref resolves the release train (publishes only :vX.Y.Z), a main push resolves the latest train (publishes only :latest), and a manual workflow_dispatch resolves a dry-run that builds locally and mutates nothing. The two runs now write DISJOINT tag sets and never collide. The shared oci-build/get-tags.nu helper is rewritten to take --mode (release|latest|dry-run) and return a { mode, train, tag, describe } record; both workflows gain a workflow_dispatch dry_run / simulate_tag input, a Resolve publish mode step, and dry-run-aware build-and-push and print steps. Image names, registry/secret wiring, gha cache strategy, build-args, Dockerfile paths are unchanged. #GOV-15 #GOV-13