Site is not rebuilt when a new release tag is pushed

[rh-hemartin]

What happens

Pushing a new release tag does not rebuild or redeploy the documentation site. After v0.39.0 (release), https://fullsend.sh/docs/v/ is not a versions index. The page should exist after a tagged release.

The Release workflow ran for v0.39.0 (run). No Build Site run was created for that tag. The last production Build Site run on main was the merge of #6010 at d9e8bec (run), about 37 minutes before the tag.

What should happen

A new v* tag should rebuild the site and publish a versions index at https://fullsend.sh/docs/v/ that includes that release.

How to reproduce

1. Push an annotated v* tag (observed with v0.39.0).
2. Confirm the Release workflow runs for the tag.
3. Open https://fullsend.sh/docs/v/.

Context

Multi-version docs shipped in #5717. Readers of a tagged release have no versions page for that release until something else happens to rebuild the site.

Related: #5717.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 3:06 PM UTC · Completed 3:11 PM UTC

Commit: 1cdaabb · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $0.89

[fullsend-ai-triage]

Root cause: site-build.yml has no tag-push trigger -- it only fires on push to main (with path filters) and pull_request. The Release workflow (release.yml) does match v* tags, but the site build/deploy pipeline is a separate chain (site-build.yml then site-deploy.yml via workflow_run) that is never entered on a tag push.

Recommended fix: Add a tags pattern (e.g., v[0-9]+.[0-9]+.[0-9]+*) under the push: trigger in site-build.yml. Tag push events carry no file diff, so path filters should not apply to the tag trigger (use a separate push block or ensure path filters are only on the branch trigger). The deploy workflow's existing push event condition should handle the rest.

Concurrency note: The current concurrency group uses github.ref, which will be the tag ref -- this should naturally avoid collisions with main branch builds.

⚠️ This fix requires modifying a workflow file (.github/workflows/site-build.yml). The code agent cannot modify workflow files under current permissions -- a human PR or maintainer action is required.

Proposed test:

1. Push a pre-release tag (e.g., v0.39.1-rc.1)
2. Confirm Build Site workflow runs for the tag event
3. Confirm Deploy Site fires via workflow_run
4. Verify /docs/v/ includes the new version
5. Verify concurrent main pushes do not cancel tag builds

---

Labels: CI workflow bug affecting the documentation site -- type/bug for confirmed defect, component/ci for the workflow trigger gap, component/docs for the affected documentation site, and priority/high because every release is impacted.

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance