fix(ci): validate the dispatch tag in release.yml (#71)

* fix(ci): validate the dispatch tag in release.yml

Gap I introduced in #63, caught in review of the same port to hotdata-ibis
(hotdata-dev/hotdata-ibis#44). publish.yml got a pre-checkout guard on the
dispatch input; release.yml did not, despite needing it more.

release.yml holds contents: write, and action-gh-release CREATES a tag when
tag_name does not resolve to one. So an unvalidated `tag: main` checks out
cleanly and then leaves refs/tags/main plus a release named for it, both needing
manual cleanup. publish.yml at worst wastes a run. The push path is constrained
by the v[0-9]* tag filter; the dispatch path had no constraint at all.

Same guard and same strict form as publish.yml, so the input contract matches in
both. sdk-python already had this -- its dispatch predates this work.

* fix(ci): give publish.yml the same strict dispatch guard

My description claimed parity between the two workflows and it was not true. In
this repo publish.yml never gained a pre-checkout step -- #63 only switched its
existing "Verify tag matches pyproject version" check to $TAG, which runs AFTER
checkout and is looser (^v[0-9]). So `-f tag=v1.2` or `v1.2.3rc1` was accepted
there and rejected in release.yml.

Tightening publish.yml rather than loosening release.yml, since release.sh only
ever produces X.Y.Z -- it enforces ^[0-9]+\.[0-9]+\.[0-9]+$ on explicit versions,
so the strict form is the correct contract. Both workflows now validate the same
input the same way, before fetching an arbitrary ref.

The post-checkout version match stays: it catches a tag that is well-formed but
does not match pyproject.

Author: anoop-narang

.github/workflows/publish.yml

@@ -31,6 +31,21 @@ jobs:
       # The tag being released, whether it arrived by push or by dispatch.
       TAG: ${{ inputs.tag || github.ref_name }}
     steps:
+      # Before checkout, because checkout resolves the input as an arbitrary ref:
+      # a branch or SHA is fetched first and only rejected later by the version
+      # match below, which is also looser (`^v[0-9]`). Strict here so the dispatch
+      # contract matches release.yml — release.sh only ever produces X.Y.Z.
+      - name: Validate release tag format
+        if: github.event_name == 'workflow_dispatch'
+        env:
+          INPUT_TAG: ${{ inputs.tag }}
+        run: |
+          set -euo pipefail
+          if [[ ! "$INPUT_TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+            echo "tag must look like vX.Y.Z, got: $INPUT_TAG" >&2
+            exit 1
+          fi
+
       - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
         with:
           ref: ${{ inputs.tag || github.ref_name }}

.github/workflows/release.yml

@@ -25,6 +25,24 @@ jobs:
       # The tag being released, whether it arrived by push or by dispatch.
       TAG: ${{ inputs.tag || github.ref_name }}
     steps:
+      # Before checkout, because checkout resolves the input as an arbitrary ref
+      # — and this workflow needs the guard more than publish.yml does. It holds
+      # `contents: write`, and action-gh-release CREATES a tag when tag_name does
+      # not resolve to one, so an unvalidated `tag: main` would check out cleanly
+      # and leave refs/tags/main plus a release named for it. The push path is
+      # constrained by the v[0-9]* filter; the dispatch path was not constrained
+      # at all.
+      - name: Validate release tag format
+        if: github.event_name == 'workflow_dispatch'
+        env:
+          INPUT_TAG: ${{ inputs.tag }}
+        run: |
+          set -euo pipefail
+          if [[ ! "$INPUT_TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+            echo "tag must look like vX.Y.Z, got: $INPUT_TAG" >&2
+            exit 1
+          fi
+
       - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
         with:
           ref: ${{ inputs.tag || github.ref_name }}