fix(release): a draft keeps its tag when its notes are written, and a release just made is waited for #2626

Open

notquiteog wants to merge 1 commit from notquiteog/fix/release-draft-tag-name into main

notquiteog commented

2026-11-12 03:18:41 +00:00

(Migrated from github.com)

Why

GitHub gives a draft release an untagged-... tag_name when it is changed without its tag_name. release_files.sh finish writes the notes with {body} alone, so the draft was no longer found by its tag one call later (id_of in the same finish). Reproduced on the draft by hand: a PATCH with the body alone resets the tag, the same PATCH with tag_name keeps it. publish on such a draft would also tag the commit untagged-....
A release just made is not in the list of releases at once. The repository's first nightly ("nightly has no release", Windows' release job) and first rc ("rc: its release could not be made", with the release there, empty) were made and not found a second later.

What changed

Every change of a release sends its tag_name: finish, publish, Promote's notes (release_promote.sh) and release_rc.sh.
After making nightly, rc or a hand-pushed tag's release, the scripts look for it a few times (3 s apart) before giving up.
tests/test_release_scripts.py's fake GitHub does what GitHub does to a draft changed without its tag. With the scripts as they were, two of its checks fail; with these they pass.

Tested

python -I -B tests/test_release_scripts.py (24 checks). On notquiteog/Hookshot the fixed scripts finished and published v2.2.0-rc.1's draft, tag kept, SHA256SUMS attached.

Not part of this: test_nightly_two_runs_at_once_end_at_the_newer_commit fails about one run in four on main as it is (its two runs race to "SHA256SUMS still differs from the files after 5 uploads"), before and after this change.

🤖 Generated with Claude Code

A fork's first release candidate through the Release workflow stopped at the publish job with "v2.2.0-rc.1 has no release", although its draft was there with every file on it. The draft had lost its tag. **Why** - GitHub gives a draft release an `untagged-...` `tag_name` when it is changed without its `tag_name`. `release_files.sh finish` writes the notes with `{body}` alone, so the draft was no longer found by its tag one call later (`id_of` in the same `finish`). Reproduced on the draft by hand: a PATCH with the body alone resets the tag, the same PATCH with `tag_name` keeps it. `publish` on such a draft would also tag the commit `untagged-...`. - A release just made is not in the list of releases at once. The repository's first `nightly` ("nightly has no release", Windows' release job) and first `rc` ("rc: its release could not be made", with the release there, empty) were made and not found a second later. **What changed** - Every change of a release sends its `tag_name`: `finish`, `publish`, Promote's notes (`release_promote.sh`) and `release_rc.sh`. - After making `nightly`, `rc` or a hand-pushed tag's release, the scripts look for it a few times (3 s apart) before giving up. - `tests/test_release_scripts.py`'s fake GitHub does what GitHub does to a draft changed without its tag. With the scripts as they were, two of its checks fail; with these they pass. **Tested** `python -I -B tests/test_release_scripts.py` (24 checks). On notquiteog/Hookshot the fixed scripts finished and published v2.2.0-rc.1's draft, tag kept, `SHA256SUMS` attached. Not part of this: `test_nightly_two_runs_at_once_end_at_the_newer_commit` fails about one run in four on `main` as it is (its two runs race to "SHA256SUMS still differs from the files after 5 uploads"), before and after this change. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

github-sync referenced this pull request

2026-11-12 07:27:38 +00:00

perf(build): keep unchanged button-prompt assets in source builds #2698

github-sync referenced this pull request from a commit

2026-11-12 08:30:49 +00:00

perf(build): keep unchanged button-prompt assets in source builds (#2698)

github-sync referenced this pull request

2026-11-12 12:37:09 +00:00

fix(release): wait before the final checksum validation #2779

github-sync commented

2026-11-12 14:43:33 +00:00

Owner

@Joey-Magnus approved on GitHub · 2026-11-12 14:33 UTC · original

I merged this into current main (it merges cleanly) and ran tests/test_release_scripts.py three times. All 33 tests passed each time. I then put main's scripts back under the new fake GitHub. test_finish_puts_the_table_with_the_zip_under_the_notes_once and test_prepare_again_goes_on_with_its_draft fail there, so the fake's "untagged-" behaviour really catches the bug.
I went through the scripts for any other PATCH of a release that could drop the tag. All of them now send tag_name: finish and publish in release_files.sh, prepare in release_promote.sh, and both calls in release_rc.sh. The only gh release edit left is on nightly in release_upload.sh, which is never a draft. The retry loops (six tries, 3 s apart) are bounded and only run after a create, so a release that already exists is found on the first try.
The red CI is main's own failures from early Nov 12, so a re-run should clear it. The flaky nightly race you mention is on main and isn't touched here.

> [@Joey-Magnus](https://github.com/Joey-Magnus) approved on GitHub · 2026-11-12 14:33 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2626#pullrequestreview-5876224069) I merged this into current main (it merges cleanly) and ran tests/test_release_scripts.py three times. All 33 tests passed each time. I then put main's scripts back under the new fake GitHub. test_finish_puts_the_table_with_the_zip_under_the_notes_once and test_prepare_again_goes_on_with_its_draft fail there, so the fake's "untagged-" behaviour really catches the bug. I went through the scripts for any other PATCH of a release that could drop the tag. All of them now send tag_name: finish and publish in release_files.sh, prepare in release_promote.sh, and both calls in release_rc.sh. The only gh release edit left is on nightly in release_upload.sh, which is never a draft. The retry loops (six tries, 3 s apart) are bounded and only run after a create, so a release that already exists is found on the first try. The red CI is main's own failures from early Nov 12, so a re-run should clear it. The flaky nightly race you mention is on main and isn't touched here.

github-sync referenced this pull request

2026-11-12 15:49:09 +00:00

fix(release): a SHA256SUMS replaced between its listing and its read is read again (flaky nightly test) #2822

github-sync referenced this pull request from a commit

2026-11-12 17:57:20 +00:00

fix(release): a SHA256SUMS replaced between its listing and its read is read again (flaky nightly test) (#2822)

github-sync referenced this pull request

2026-11-12 17:59:31 +00:00

ci: label-gated hardware tests on testers' self-hosted runners, through the owner's sandbox #2807

github-sync referenced this pull request from a commit

2026-11-12 20:15:23 +00:00

fix(release): a draft keeps its tag when its notes are written, and a release just made is waited for (#2626)