From 1a00ea39b98c7f7b5365c442c20aea26f02de9f6 Mon Sep 17 00:00:00 2001 From: Rockford Lhotka Date: Sat, 9 May 2026 13:08:00 -0500 Subject: [PATCH] ci: drop 'released' from release-workflow triggers `gh release create` (the normal release path) emits both `published` and `released` events, so listening to both fires the build-and-upload job twice. Both runs upload with --clobber, but it's wasted CI time. Drop `released`; rely on `published` plus the existing `workflow_dispatch` recovery path documented in the README. Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/workflows/release.yml | 2 +- README.md | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index a092fd4..8d19dbc 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -2,7 +2,7 @@ name: Release on: release: - types: [published, released] + types: [published] workflow_dispatch: inputs: tag: diff --git a/README.md b/README.md index 38231b5..44de130 100644 --- a/README.md +++ b/README.md @@ -322,9 +322,8 @@ After 1.0 the standard SemVer rules kick in (breaking → major, additive → mi ### If the release workflow didn't fire GitHub's `release: published` event is occasionally missed — usually -when the Release was created from a pre-existing tag via API. The -workflow listens for both `published` and `released` activity types as -a defensive measure, but it can still happen. Two recovery paths: +when the Release was created from a pre-existing tag via API. Two +recovery paths: - **Manual dispatch** (preferred): trigger the workflow against the existing tag without touching the Release.