4 Commits

Include renames

Author	SHA1	Message	Date
flan	8c1b4c45f5	release: rc notes resolve to the base version; publish without jq ... release_notes.py 'notes v0.6.0-rc1' looked for a CHANGELOG section literally named v0.6.0-rc1. check() already used base_version(); extract_notes() did not. So the release workflow cut the tag, passed every gate, and then died extracting the body -- the candidate existed but was never published. Caught in an rc, which is the entire point of having them. Also: the Gitea publish and issue steps used jq, which is not guaranteed on a self-hosted runner. A publish step that dies on a missing tool leaves a tag with no release behind it, and a bug report that dies on one is a warning system that does not warn. Both now use python3, which setup-python guarantees.	2026-07-13 18:38:02 +00:00
flan	5cbb7def6f	Compatibility watch: check the patch's assumptions against every TrueNAS release line ... TrueNAS 26 rewrites cloud_backup from async to sync. Every block the nested module injects is an async wrapper around an awaited original, so on 26 it hands sync.py a coroutine where it unpacks a tuple. tools/compat.py records what each module assumes and checks it two ways: CI runs it against iX's source at every release line (including master and the current BETA) and files a bug report when an unreleased line breaks; apply.sh runs it against the middlewared actually installed and refuses to apply a module whose assumptions no longer hold. Stock TrueNAS without a feature beats TrueNAS with a broken one. Workflows run on both forges; only the release/issue API calls differ.	2026-07-13 17:25:37 +00:00
flan	4e0814028c	v0.5.0: TrueNAS alert when an update is available ... Raises a real alert in the TrueNAS UI bell -- not a log line nobody reads. On by default, checked once a day. install.sh --no-update-alerts turns it off. It does not nag --------------- A release whose CHANGELOG contains only a "### Docs" section changed no code and raises nothing. Anything else raises INFO; a "### Security" section raises WARNING. The CHANGELOG's own section headings are the signal, and a security fix anywhere in the range escalates the whole span -- a docs-only release sitting on top of a security fix still reports as security rather than hiding it. Why an AlertSource and not midclt ---------------------------------- TrueNAS cannot raise an alert from the CLI. midclt exposes only alert.dismiss, alert.list, alert.list_categories, alert.list_policies and alert.restore -- alert CREATION is internal to middlewared, and none of its ~60 one-shot classes is generic enough to reuse. Registering an AlertSource is the only way. It is also the least invasive thing this patch does. The providers and nested modules both APPEND CODE TO STOCK middleware files; the alert source ADDS ONE FILE and modifies none. It is the native mechanism -- the same one every built-in TrueNAS alert uses -- and TrueNAS polls it itself, so there is no cron job and no systemd timer. - Fail-safe: every error path returns None; it cannot take middlewared down. - Read-only: `git ls-remote` plus an HTTPS fetch of the CHANGELOG. It never writes to .git, so it cannot leave root-owned objects behind the way a `git fetch` from middlewared (running as root) would. - Removed by uninstall.sh (mw_patch.revert_all). - It only tells you; it never updates anything. Verified against the real repo and remote, with middlewared stubbed: on v0.4.1, only a README-only v0.4.2 available -> NO ALERT on v0.4.0, v0.4.1 fixed real bugs -> INFO on v0.3.2, v0.3.3 was the password fix -> SECURITY / WARNING 139 tests, ruff and shellcheck -S style clean.	2026-07-13 16:45:26 +00:00
flan	eb91a337cd	Automate releases from tags ... Releases were manual and had drifted: v0.2.0 and v0.2.1 were tagged but never released, so the releases page jumped v0.1.0 -> v0.3.0 and hid the fix for the incident that took every app down. Pushing a v* tag now runs the full suite and cuts a GitHub release whose body is the matching CHANGELOG.md section -- one source of truth for release notes, so there is no second place for them to be wrong. The workflow refuses to publish when: - the tests, ruff, or bash -n fail (a tagged commit is what people install; it must be at least as good as main) - the tag does not match the VERSION= declared by every script - CHANGELOG.md has no section for the tag, or the section is empty That version check is not theoretical: VERSION= had drifted to three different values across install.sh / uninstall.sh / recover.sh / apply.sh and nothing noticed until this release. tests/test_release_notes.py now asserts the scripts agree with each other and with the newest CHANGELOG entry, so the drift cannot come back. workflow_dispatch takes an existing tag, so releases can be backfilled for tags that were pushed before this existed. 106 tests, ruff and shellcheck clean.	2026-07-13 15:05:46 +00:00