From 044d4d1be9e402dcbf4049587d7c1fb53b125f58 Mon Sep 17 00:00:00 2001 From: Asad Iqbal Date: Thu, 7 May 2026 16:38:37 +0500 Subject: [PATCH 1/3] ci: drop push-tags trigger from release-helm-chart workflow MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `gh release create v` (the established release path per `gh release list`) fires both `push` (tag) and `release` (published) events, which causes two parallel workflow runs to race for the gh-pages push. The slower run fails with non-fast-forward. Most recent example: v1.3.2 cut today — run 25492826437 (release event) failed; run 25492826350 (push event) succeeded. Artifacts landed fine, but the failed sibling shows up as a red X on the release and is noise for anyone debugging future releases. Keeping only `release: published` removes the race. The `Upload chart to GitHub Release (on tag)` step's `startsWith(github.ref, 'refs/tags/')` guard still evaluates true for release events (`github.ref` is the tag ref), so the upload step behaviour is preserved. Closes #116 --- .github/workflows/release-helm-chart.yaml | 4 ---- 1 file changed, 4 deletions(-) diff --git a/.github/workflows/release-helm-chart.yaml b/.github/workflows/release-helm-chart.yaml index 5593c24..b8e464f 100644 --- a/.github/workflows/release-helm-chart.yaml +++ b/.github/workflows/release-helm-chart.yaml @@ -6,10 +6,6 @@ name: Release Helm Chart on: - push: - tags: - - 'client-v*' - - 'v*' release: types: [published] From 12c7a4cd5924a46acd9cf6445c634b7ca292364e Mon Sep 17 00:00:00 2001 From: Asad Iqbal Date: Thu, 7 May 2026 16:55:05 +0500 Subject: [PATCH 2/3] ci: harden release-asset upload against actions/runner#2788 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit With the push-tags trigger removed, the upload step's `if: startsWith(github.ref, 'refs/tags/')` guard is the only thing keeping the upload from running, but it silently evaluates to false when `github.ref` arrives empty — a known intermittent runner bug (actions/runner#2788, still open as of 2026-05). The same bug also affects `github.ref_name`, which softprops/action-gh-release@v2 uses by default to derive the tag, so the action itself can target the wrong release (or fail) when the bug fires. Drop the now-redundant `if:` guard (the workflow only runs on `release: published`, so every run is by definition a release event) and pass `tag_name` explicitly from the release event payload, which is unaffected by the bug. --- .github/workflows/release-helm-chart.yaml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/.github/workflows/release-helm-chart.yaml b/.github/workflows/release-helm-chart.yaml index b8e464f..7d4a974 100644 --- a/.github/workflows/release-helm-chart.yaml +++ b/.github/workflows/release-helm-chart.yaml @@ -97,10 +97,13 @@ jobs: git push origin gh-pages fi - - name: Upload chart to GitHub Release (on tag) - if: startsWith(github.ref, 'refs/tags/') + - name: Upload chart to GitHub Release + # Pin tag_name from the release event payload rather than relying on + # github.ref / github.ref_name, which intermittently arrive empty on + # release-triggered runs (actions/runner#2788, still open). uses: softprops/action-gh-release@v2 with: + tag_name: ${{ github.event.release.tag_name }} files: client-*.tgz generate_release_notes: true env: From 4466e0c4e94eccc3dff8199ea0e6cd1005940a41 Mon Sep 17 00:00:00 2001 From: Asad Iqbal Date: Thu, 7 May 2026 17:29:36 +0500 Subject: [PATCH 3/3] ci: pin checkout ref to release tag (actions/runner#2788 hardening) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit actions/checkout@v4 defaults `ref` to github.ref, which is the same field hit by actions/runner#2788 — the still-open intermittent bug where github.ref arrives empty on release-triggered runs. Per the action's docs, when "checking out the repository that triggered a workflow, this defaults to the reference or SHA for that event. Otherwise, uses the default branch." So an empty github.ref would fall back to the repo default branch (develop here), and we'd package the chart from develop's HEAD instead of the tagged commit. Pin ref explicitly to github.event.release.tag_name, which is part of the release event payload and is unaffected by the runner bug. --- .github/workflows/release-helm-chart.yaml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/.github/workflows/release-helm-chart.yaml b/.github/workflows/release-helm-chart.yaml index 7d4a974..4bc015b 100644 --- a/.github/workflows/release-helm-chart.yaml +++ b/.github/workflows/release-helm-chart.yaml @@ -22,8 +22,14 @@ jobs: id-token: write steps: - name: Checkout + # Pin ref to the release tag rather than letting checkout default to + # github.ref, which intermittently arrives empty on release-triggered + # runs (actions/runner#2788, still open). An empty default would cause + # checkout to fall back to the repo default branch and package the + # chart from the wrong commit. uses: actions/checkout@v4 with: + ref: ${{ github.event.release.tag_name }} fetch-depth: 0 - name: Set up Helm