ci: drop push-tags trigger from release-helm-chart workflow

[saadqbal]

Summary

• Removes the push: tags: ['client-v*', 'v*'] trigger from .github/workflows/release-helm-chart.yaml, keeping only release: types: [published].
• Eliminates the race between the two parallel runs that gh release create fires (tag push + release published), where the slower run fails with cannot lock ref ... non-fast-forward on the gh-pages push.

Why

gh release create v<x.y.z> is the established release path (see gh release list — every release v1.0.0 through v1.3.2 was created this way). It fires both push (tag) and release (published) events simultaneously, so the workflow ran twice for every release and one of the two consistently failed when racing on gh-pages.

Most recent failure: v1.3.2 cut today (2026-05-07).

• Run 25492826350 — event: push — succeeded
• Run 25492826437 — event: release — failed (gh-pages push rejected)

Artifacts (client-1.3.2.tgz, updated index.yaml, release asset) landed correctly, but the failed sibling clutters the release page.

The release-asset upload step (if: startsWith(github.ref, 'refs/tags/')) still evaluates true under the release event, since github.ref is the tag ref on a release event — no behaviour change.

Closes #116.

Test plan

• Next gh release create v<x.y.z> produces exactly one workflow run, with event: release.
• No failed sibling run on the release page.
• client-<version>.tgz published to gh-pages, index.yaml updated, and release asset attached as before.

🤖 Generated with Claude Code

---

Note

Medium Risk
Workflow-only change, but it affects the release pipeline; misconfiguration could cause charts to be packaged from the wrong commit or fail to publish/upload during releases.

Overview
Publishes Helm charts only from release: published events by removing the tag push trigger, avoiding duplicate/racing runs that compete to push updates to gh-pages.

Hardens release-triggered runs by explicitly checking out and uploading assets using github.event.release.tag_name (instead of github.ref), preventing intermittent empty-ref issues that could package or attach charts from the wrong commit.

^{Reviewed by Cursor Bugbot for commit 4466e0c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LukasWodka]

👋 Heads-up — Code review queue is at 11 / 8

Above the WIP limit. The team convention is to review existing PRs before opening new work.

Open PRs currently in Code review (oldest first):

• docs#14 — docs: migrate join-use-case API examples to snake_case (0.7.0) · author: @divyasinghds · no reviewer assigned
• docs#26 — docs: add "How training works" page · author: @divyasinghds · no reviewer assigned
• docs#4 — docs: switch install to extras syntax for tracebloc_package 0.6.33 · author: @LukasWodka · reviewer: @saadqbal
• documentation-lagecy-#7 — docs: migrate start-training and hyperparameters to snake_case API (0.7.0) · author: @aptracebloc · reviewer: @LukasWodka
• frontend-app#455 — fix: show correct flops-per-participant on admin use case details before any team joins · author: @waqaskhanroghani · no reviewer assigned
• start-training#10 — ci: add WIP-limit-check caller workflow · author: @LukasWodka · no reviewer assigned
• start-training#6 — chore: add PR template + customer bump + stale auto-close · author: @LukasWodka · no reviewer assigned
• start-training#9 — ci: add kanban closure-routing caller workflow · author: @LukasWodka · reviewer: @saadqbal
• tracebloc-website#276 — docs(homepage): fix Colab install snippet to use tracebloc_package with extras · author: @LukasWodka · reviewer: @saadqbal

Pull from review before opening new work. (This is a nudge from the kanban WIP check, not a block.)

[saadqbal]

Pushed 12c7a4c addressing review feedback on the previous commit.

The original PR removed the push: tags trigger but left if: startsWith(github.ref, 'refs/tags/') on the release-upload step. That guard relies on github.ref being populated on release events, which is the subject of actions/runner#2788 — a still-open intermittent bug where github.ref (and github.ref_name) arrive empty on release-triggered runs. With the push-tags fallback gone, an empty github.ref would silently skip the upload and ship a release with no .tgz asset.

softprops/action-gh-release@v2 defaults to github.ref_name for the target tag, so the action itself is also vulnerable to the same bug.

Two changes:

1. Drop the if: startsWith(github.ref, 'refs/tags/') guard. Redundant now that the workflow only triggers on release: published — every run is a release event by construction.
2. Pass tag_name: ${{ github.event.release.tag_name }} explicitly to the action. The release event payload is unaffected by the runner bug (confirmed in the issue thread comments), so the upload always targets the correct release.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 12c7a4c. Configure here.}

[saadqbal]

Pushed 4466e0c addressing the second review note on the checkout step.

Same root cause as the previous fix — actions/checkout@v4 defaults ref to github.ref, so actions/runner#2788 firing during checkout would, per the action's docs, fall back to the repo default branch (develop) and package the chart from develop's HEAD instead of the tagged commit.

Pin ref: ${{ github.event.release.tag_name }} so checkout uses the release event payload, which the runner bug doesn't affect.

After this commit, all three release-event-dependent steps (checkout, gating, asset upload) source the tag from github.event.release.tag_name rather than github.ref / github.ref_name, so a single empty-github.ref incident can no longer corrupt or skip the release.