Skip to content

fix(ci): resolve release tag from manifest so CD_production deploys - #759

Merged
jirhiker merged 2 commits into
stagingfrom
fix/release-please-tag-from-manifest
Jul 6, 2026
Merged

fix(ci): resolve release tag from manifest so CD_production deploys#759
jirhiker merged 2 commits into
stagingfrom
fix/release-please-tag-from-manifest

Conversation

@jirhiker

@jirhiker jirhiker commented Jul 6, 2026

Copy link
Copy Markdown
Member

What

Replace the broken tag_name passthrough in release-please.yml with a manifest-derived tag resolver, so the production deploy (and forward-merge) actually receive the release tag.

Why

release-please-action@v5 does not populate a usable tag_name output in this manifest configuration. The action's run log shows it emits exactly two outputs — release_created and an empty tag_name — and no path-scoped (.--tag_name) outputs exist at all.

Consequence: CD_production's job gate

if: ${{ startsWith(inputs.tag_name || github.event.release.tag_name, 'v') }}

receives an empty inputs.tag_namestartsWith('', 'v') = false → the deploy job silently skips. Observed on both v1.1.1 and v1.1.2 (run 28806722930, 28808275126): the release/tag were created, the reusable workflow was invoked (so release_created propagated), but the inner job self-skipped. Both releases had to be shipped by manually re-publishing the GitHub release to fire the release: published path.

The forward-merge job consumes the same tag_name, so it was getting an empty tag too.

Fix

After the release step, resolve the tag from the released version in the branch-appropriate manifest:

tag="$ACTION_TAG"                       # prefer the action output if ever non-empty
if [ -z "$tag" ]; then
  version="$(jq -r '.["."]' "$MANIFEST")"
  tag="v${version}"                     # include-v-in-tag: true in both configs
fi
  • MANIFEST follows the same staging/stable switch already used for manifest-file.
  • Fails loudly if the version can't be read (no more silent skips).
  • Only runs when release_created == 'true'.

Supersedes

PR #756 (already merged) added a .--tag_name fallback based on a path-scoped output key this configuration never emits — so it had no effect. This PR removes that dead fallback and replaces it with the manifest-derived resolver.

Note

This is CI-only. It needs to reach production (and thus future hotfix/* branches cut from release tags) via the normal forward-merge flow to fix auto-deploy on those lines.

🤖 Generated with Claude Code

jirhiker and others added 2 commits July 6, 2026 11:04
release-please-action@v5 does not populate a usable `tag_name` output in
this manifest setup — it emits `release_created` plus an EMPTY `tag_name`
and no path-scoped outputs. The empty tag made CD_production's
`startsWith(inputs.tag_name, 'v')` gate silently skip the production
deploy (observed on v1.1.1 and v1.1.2, which had to be shipped by
re-publishing the release manually). It also handed the forward-merge
job an empty tag.

Resolve the tag ourselves from the released version in the
branch-appropriate manifest (`v<version>`, include-v-in-tag: true),
preferring the action's own output if it is ever non-empty.

Supersedes PR #756's `.--tag_name` fallback, which targeted a
path-scoped output key this configuration never emits.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Document the 2026-07-06 site-wide 500/503 outage: blank-instanceId
requests dying in the pending queue, root cause (no
max_concurrent_requests vs 4 gunicorn workers → scheduler pins bursts to
one instance instead of scaling out), the three-part config fix
(max_concurrent_requests: 6, MIN_INSTANCES=1, -w 8), verification, and
tuning notes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@jirhiker
jirhiker merged commit 0ace58e into staging Jul 6, 2026
9 checks passed
@jirhiker
jirhiker deleted the fix/release-please-tag-from-manifest branch July 6, 2026 19:01
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