From f34849135659c0ab9708f94f892c85d55de8b171 Mon Sep 17 00:00:00 2001
From: Vincent Giersch <vincent@giersch.fr>
Date: Fri, 11 Sep 2026 14:46:40 +0200
Subject: [PATCH] fix(release): one GitHub release step, not two

The v2.0.1 release failed:

  HTTP 422: Validation Failed
  Release.tag_name already exists

release.yml carried the step twice. The first named the release for the version
with the v stripped, which is how the 2.0.0 and 2.0.1 releases already on this
repository were created, so creating 2.0.1 a second time was refused. The
duplicate arrived when the v-prefix change was applied on top of a file that
already had the step.

The two are merged into one: the changelog lookup and the install line from the
first, the existence guard from the second, and the release named for the tag
rather than the stripped version, so a vX.Y.Z tag produces a vX.Y.Z release.

The bare 2.0.0 and 2.0.1 releases are left alone. They point at the tags that
were actually published, and renaming them would break any link anyone holds.
---
 .github/workflows/release.yml | 25 ++++---------------------
 1 file changed, 4 insertions(+), 21 deletions(-)

diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index 2b150d2..80cbc1c 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -71,26 +71,8 @@ jobs:
         env:
           GH_TOKEN: ${{ github.token }}
         run: |
-          # Every tag in this repository, and in api-reference, carries the v. The version
-          # inside the package never does, so the tag is compared with it stripped.
-          TAG="${GITHUB_REF_NAME#v}"
-          NOTES="$(awk -v tag="$TAG" '
-            $0 ~ "^## \\[?" tag {found=1; next}
-            found && /^## / {exit}
-            found {print}
-          ' CHANGELOG.md)"
-          [ -n "$NOTES" ] || NOTES="See CHANGELOG.md for the changes in $TAG."
-          printf '%s\n\n---\n\nInstall: `pip install flat-api==%s`\n' "$NOTES" "$TAG" \
-            > /tmp/notes.md
-          gh release create "$TAG" --title "$TAG" --notes-file /tmp/notes.md --verify-tag
-
-      # The tag alone left the repository's Releases page showing a version from years ago as
-      # "Latest", which is what anyone browsing the repository sees first. The notes come from the
-      # CHANGELOG section for this version, so the release says what changed rather than nothing.
-      - name: Publish the GitHub release
-        env:
-          GH_TOKEN: ${{ github.token }}
-        run: |
+          # The release is named for the tag. The version inside the package never carries the v,
+          # so the changelog lookup and the install line use it stripped.
           VERSION="${GITHUB_REF_NAME#v}"
           NOTES="$(awk -v v="$VERSION" '
             $0 ~ "^## \\[?" v "\\]?" { found = 1; next }
@@ -98,10 +80,11 @@ jobs:
             found { print }
           ' CHANGELOG.md)"
           [ -n "$NOTES" ] || NOTES="See CHANGELOG.md for $VERSION."
+          printf '%s\n\n---\n\nInstall: `pip install flat-api==%s`\n' "$NOTES" "$VERSION" > /tmp/notes.md
           # Creating one that exists is an error, and a re-run of a release that already happened
           # should be a no-op rather than a red build.
           if gh release view "$GITHUB_REF_NAME" >/dev/null 2>&1; then
             echo "Release $GITHUB_REF_NAME already exists; nothing to do."
           else
-            gh release create "$GITHUB_REF_NAME" --title "$GITHUB_REF_NAME" --notes "$NOTES"
+            gh release create "$GITHUB_REF_NAME" --title "$GITHUB_REF_NAME" --notes-file /tmp/notes.md --verify-tag
           fi