ADR 0048 — Track B: Align deploy-antlers.yml tag trigger with release-please tag format

Status: Accepted
Date: 2026-05-03
Deciders: software-architect
Context doc: raxx-app-track-b.md §8
Parent epic: #94

Context

deploy-antlers.yml triggers on tags matching v*.*.* (bare semver). Release-please, configured with package-name: trademaster-api, produces tags in the format trademaster-api-v1.10.1. These two patterns do not match. As a result, pushing a release-please tag will never trigger deploy-antlers.yml, and Antlers will never automatically deploy to production on a release. The operator would have to manually push a duplicate bare-semver tag or manually trigger the workflow.

The same release.yml post-release verification job already expects the trademaster-api-v*.*.* format (the api_tag_name output strips the prefix correctly). Changing the release-please config would break release.yml.

Decision

Update deploy-antlers.yml to trigger on trademaster-api-v*.*.* tags instead of v*.*.*.

Also update the startsWith(github.ref, 'refs/tags/v') conditionals inside the workflow — which control environment name, API URL, and CF Pages branch slug — to startsWith(github.ref, 'refs/tags/trademaster-api-v').

Do not change .release-please-config.json.

Consequences

Positive

• Release-please tags automatically trigger Antlers production deploys. No manual step required after merging a release PR.
• The release.yml post-release job and deploy-antlers.yml are now consistent on tag format. Both use trademaster-api-v*.*.*.
• The change is contained to one file (deploy-antlers.yml). Low blast radius.

Negative / risks

• Any manually-pushed bare v*.*.* tag will no longer trigger Antlers production deploy. This is the correct behavior — bare tags should not trigger production deploys outside the release-please flow.
• The CF Pages --branch flag will receive trademaster-api-v1.10.1 as the branch slug instead of v1.10.1. CF Pages treats this as a named deployment and it maps to the production alias via the --project-name=raxx-app flag, so there is no functional change. The branch slug in the CF dashboard will look like a tag name rather than a version number, which is slightly cosmetic but not a problem.

Alternatives considered

A: Change release-please package-name to an empty string so it produces bare v*.*.* tags

Rejected. release.yml already expects trademaster-api-v*.*.* in its api_tag_name parsing and SEMVER="${TAG#trademaster-api-v}" extraction. Changing the tag format would break release.yml version-file verification, which is a CI correctness gate.

B: Add a second trigger v*.*.* in addition to trademaster-api-v*.*.*

Rejected. Two valid trigger patterns for the same production deploy creates ambiguity about which tag should be used. It also reopens the risk of a stale bare-semver tag accidentally deploying a different ref than the release-please-managed tag.

C: Keep current mismatch; require manual workflow_dispatch for all production deploys

Rejected. The deploy-heroku.yml workflow already uses workflow_dispatch for Raptor production deploys (intentional friction model per prod-deploy-gating.md). Antlers deploys are a static CF Pages publish with no live-traffic risk comparable to a Heroku dyno restart. The friction model does not apply here; automation is appropriate.