From f83f239c2b8d85b45a78e9c09caa32d8e8cd6953 Mon Sep 17 00:00:00 2001
From: fadeltd <fadeltd@hotmail.com>
Date: Thu, 24 Sep 2026 15:37:36 +0700
Subject: [PATCH] Always dispatch Deploy from Release
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Releases have been tagging correctly and never deploying. v0.2.1 was tagged,
Release reported success, and the Deploy workflow had zero runs — the site sat
on an old build while every signal said green.

The cause was a conditional I added to support an optional PAT. Release only
started Deploy when RELEASE_TOKEN was absent, on the assumption that a
PAT-pushed tag would trigger `on: push: tags` natively. Once a PAT was
configured that assumption silently took over, and the native trigger did not
fire.

Release now dispatches Deploy unconditionally. Whether a tag push triggers a
workflow depends on how GitHub attributes the pushing credential, and that is
not something a release pipeline should depend on. Deploy is idempotent — it
builds and uploads the same tag — so a duplicate run is harmless, whereas a
missed one is invisible, which is precisely the failure this had.

The wider lesson, recorded in CONTRIBUTING: a deploy that silently does not
happen is indistinguishable from one that succeeded. Prefer the deterministic
path even when the implicit one should work.
---
 .github/workflows/release.yml | 25 +++++++++++++------------
 CHANGELOG.md                  |  7 ++++++-
 CONTRIBUTING.md               |  6 ++++++
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index f1ca4a4..58482d7 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -25,11 +25,6 @@ jobs:
     runs-on: ubuntu-latest
     # Never react to our own release commit.
     if: "!contains(github.event.head_commit.message, '[skip ci]')"
-    env:
-      # A tag pushed with GITHUB_TOKEN does NOT trigger other workflows, by
-      # design, to prevent recursion. With a PAT in RELEASE_TOKEN the tag
-      # triggers Deploy natively; without one we start Deploy explicitly.
-      HAS_PAT: ${{ secrets.RELEASE_TOKEN != '' }}
     steps:
       - uses: actions/checkout@v7
         with:
@@ -91,15 +86,21 @@ jobs:
             --notes "${{ steps.cut.outputs.notes }}" \
             || echo "::notice::Release already exists."
 
-      # Only needed while no PAT is configured; with one, the tag push above
-      # has already started Deploy.
-      - name: Start Deploy (no PAT configured)
-        if: steps.cut.outputs.released == 'true' && env.HAS_PAT != 'true'
+      # Always dispatch, unconditionally.
+      #
+      # This previously only ran when no PAT was configured, on the assumption
+      # that a PAT-pushed tag would trigger Deploy natively via `on: push:
+      # tags`. With a PAT present that assumption silently took over and no
+      # deploy ever happened: the tag was pushed, Release reported success, and
+      # Deploy had zero runs. Dispatching every time removes the dependency on
+      # how GitHub attributes the push. Deploy is idempotent -- it builds and
+      # uploads the same tag -- so a duplicate run is harmless, whereas a
+      # missed one is invisible.
+      - name: Start Deploy
+        if: steps.cut.outputs.released == 'true'
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        run: |
-          echo "::notice::No RELEASE_TOKEN set, so the tag cannot trigger Deploy. Dispatching it directly."
-          gh workflow run deploy.yml --ref main -f tag="${{ steps.cut.outputs.tag }}"
+        run: gh workflow run deploy.yml --ref main -f tag="${{ steps.cut.outputs.tag }}"
 
       - name: Summary
         run: |
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 2e4e340..14faf00 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -7,7 +7,12 @@ this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
 
 ## [Unreleased]
 
-Nothing yet.
+### Fixed
+- Releases tagged correctly but never deployed. The Release workflow only
+  started Deploy when no `RELEASE_TOKEN` was configured, assuming a PAT-pushed
+  tag would trigger it natively. With a PAT present that assumption took over
+  silently: the tag was pushed, Release reported success, and Deploy had zero
+  runs. Release now always starts Deploy explicitly.
 
 ## [0.2.1] — 2026-09-24
 
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index e7baee7..e978c03 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -98,6 +98,12 @@ Merging to `main` then does the rest, automatically:
 An empty `[Unreleased]` releases nothing, so a docs-only or refactor merge ships
 nothing. That is deliberate: merging and releasing are separate decisions.
 
+Deploy is always started explicitly by Release, never left to the tag event.
+A tag pushed by automation may or may not trigger `on: push: tags` depending on
+which credential pushed it, and a deploy that silently does not happen looks
+exactly like a deploy that succeeded. Dispatching every time is deterministic,
+and Deploy is idempotent so a duplicate run is harmless.
+
 Two notes for anyone editing the workflows:
 
 - `### Removed` is deliberately a *patch*, not a major. Inferring a major bump