From d3204d6cdf303abade3259268c9f2bd4c0998be1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jaroslav=20Bene=C5=A1?= Date: Fri, 7 Aug 2026 23:59:42 +0200 Subject: [PATCH] The tag first, then the release made from it Gitea will create a release for a tag that does not exist yet, and the tag it writes is lightweight: no message, no signature. The forge page looks correct and /admin/updates shows blank release notes, because the tag object is where the application reads them from and there is nothing in it. Co-Authored-By: Claude Opus 5 (1M context) --- docs/notes/release-checklist.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/notes/release-checklist.md b/docs/notes/release-checklist.md index 892ca0e..a60c159 100644 --- a/docs/notes/release-checklist.md +++ b/docs/notes/release-checklist.md @@ -131,6 +131,12 @@ The one nobody does until it matters. the chats are there, and nothing in the log says a column is missing. - [ ] `/admin/updates` shows a version rather than a sha, and the release notes come from the tag. +- [ ] Push the **signed annotated tag first**, then make the forge Release from + it — never the other way round. A Release created for a tag that does not + exist yet makes a **lightweight** one: no message, no signature, so the + forge page looks right and `/admin/updates` shows blank release notes. + The tag is what the application reads; the Release is a second window onto + the same text, for people who never install it. - [ ] Press Update. The service restarts and comes back. - [ ] Re-run `install.sh`. The channel does **not** move on its own. *(0.9.12.)* - [ ] `sudo ls -l /usr/local/lib/lembas/update.sh` — owned by root. If systemd's