Show what changed after a self-managed update lands - #1493
Conversation
lerd update fetches and prints the changelog before asking the user to confirm, then downloads, installs, restarts services, and returns without a word about what actually changed. doctor and status both end by pointing the user at lerd whatsnew, so the two commands that did nothing advertise the changelog while the one that just applied it stays silent. Print the same changelog that was already fetched for the confirmation prompt once the update is done, gated on feedback.Interactive() so an unattended or piped run does not dump it into a log. Package-managed installs defer to apt, dnf, or brew and never reach this point.
|
Thanks for picking this one up, and sorry for the long reply, it turned out there is something broken underneath it. Tried this on a real update in a VM, 1.33.0 to 1.33.1, and the new block never printed. FetchChangelog reads CHANGELOG.md at the repo root, which is a symlink to docs/changelog.md, and raw.githubusercontent serves the link target as the body, so the parser sees no version headings and comes back empty. That has been true since April, which is also why lerd whatsnew has been answering no changelog entries found. The block earlier in update falls back to the release URL, so nothing on screen ever gave it away. Not your doing, you just landed on top of it. Two things worth changing while you are in there. It should read docs/changelog.md at the tag it just installed rather than at main, so what prints is the changelog of the version that landed and not whatever main happens to be holding. And the output wants to be a short list, the headline of each entry with its issue numbers, rather than the whole thing. I pointed the fetch at a working URL to watch it run, and the 1.33.1 changelog is around nine thousand characters, so it printed in full before the confirmation and then in full again at the end of the same run. The empty case wants mirroring too, if the fetch returns nothing the earlier block prints the release link and this one prints nothing at all. And since the short list means parsing, it should come with a test. |
FetchChangelog read CHANGELOG.md at the repo root, which is a symlink to docs/changelog.md, and raw.githubusercontent serves the symlink target as the body so the parser saw no version headings and came back empty. That has been true since April, which is also why lerd whatsnew answered no changelog entries found. The changelog is now read at docs/changelog.md pinned to the tag that just installed, so what prints is the changelog of the version that landed and not whatever main happens to be holding. The full changelog for a release is around nine thousand characters, which printed in full before the confirmation prompt and then in full again at the end of the same run. Both surfaces now print a short list of the headline of each entry with its issue numbers, keeping the section headers and dropping the prose. The empty case is mirrored too, so when the fetch returns nothing the post-update block prints the release link the same way the pre-confirmation block already did. A test covers the parser.
|
good catch on the symlink, sorry for missing it, updated |
2 participants
After a self-managed update lands, print the changelog that was already fetched for the confirmation prompt. Gated on feedback.Interactive() so unattended runs suppress it. Package-managed installs never reach this point.
Closes #1359