5 Commits

Include renames

Author	SHA1	Message	Date
admin	84ef5818d5	security-scan gate (shared felhom.eu/scripts/security_scan_gate.py) in the fast set and CI, warn-first, with the accepted-hits file and decoys (R-986)	2026-10-19 21:11:46 +02:00
admin	79ba884859	CI workflow: the failure mail links the public run page, by run id (R-1135) ... The alarm step built its link from GITHUB_SERVER_URL, which on this runner is the in-cluster Gitea address, and from the run NUMBER, which Gitea 1.26 reads as a run id first (felhom.eu /actions/runs/1116 opened run id 1116 = run number 613). Now https://gitea.dooplex.hu + GITHUB_RUN_ID, and the link is printed into the job log as ALARM-LINK. Same change in all four repos.	2026-10-18 20:34:59 +02:00
admin	344c4f9030	CI workflow: a manual proof that the failure mail can be sent (R-1129) ... workflow_dispatch with input force_alarm (default false). A dispatch-only step prints the RESEND_API_KEY length (never the key) and, when forced, fails so the alarm step sends its real mail, subject marked FORCED TEST. Push runs are unchanged. No agent release. Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS	2026-10-17 12:49:37 +02:00
admin	dd2d1feb6e	release path publishes, and an unreleasable version fails CI (R-115, R-183) ... NO VERSION BUMP and nothing built: no Go code changed. The agent stays v0.120.0. scripts/release-agent.sh — THE way to release. build -> tag -> publish -> verify by INDEPENDENT download. Publishing was a separate remembered step and was forgotten three times in five days (R-111's 17 stranded releases, 0.114.0, and 0.120.0 — deployed to both demo hosts and undownloadable, so a documented-path reinstall would have silently downgraded them WHILE REPORTING SUCCESS). R-111's own closing line named this leg and closed SHIPPED without it; it recurred the same afternoon, which is the evidence that a note is not a mechanism. It tags because felhom-host-install.sh now fetches the sixteen agent config files from raw/tag/v<version>/ (R-183): a released version with no tag 404s a box mid-install, as root, on a virgin machine. It verifies by downloading what it just published and comparing the sha to what it built — the publish step's own success is a report on its own write; a fetch returning the right bytes is a different claim. It refuses a dirty/unpushed tree and refuses to re-release an existing version. It does NOT vouch: that points machines at a version and stays the operator's act. scripts/check-published-versions.py — the gate. Every v<semver> tag must have a downloadable package AND a tag tree serving the agent's configs. Registered as NOT --fast (needs network; a push must not fail because Gitea blinked), and the CI workflow now runs the FULL gate set instead of --fast — otherwise the gate would have been registered and never run, the built-but-never-wired failure this project has shipped four times. The invariant is not the one specified, and the reason was measured, not assumed: the hub artifact manifest is 401 without a per-customer passphrase and Gitea's package LISTING api is 401 without a token, while the package DOWNLOAD url and the git TAGS api are anonymous. So CI cannot ask "what is vouched" without an operator credential — whose addition is the operator's call. The tag-based invariant needs none and catches all three recorded instances. What it does not catch (the hub vouching a version never released at all) is filed as R-184.	2026-08-03 12:34:20 +02:00
admin	eb99144509	ci: run the gate entry point on every push (R-168) ... Same shape as the other repos. CI clones felhom.eu as a sibling because the shared reuse_refs_check lives there and this repo's REUSE.md cites hub/internal/store/dr_recipe.go, which lives in the hub. No uses: step, no version bump, nothing built or deployed.	2026-08-02 16:27:27 +02:00