Repository navigation
Publish every beta and stable release to the Home Assistant add-on repository #1233
Description
Summary
Every FTW beta and stable release should reach Home Assistant users through the official add-on repository, srcfl/home-assistant-addons, without a manual step per release:
- beta cut (
beta.yml, tagvX.Y.Z-beta.N) → add-onftw-betapublishes versionX.Y.Z-beta.N, built from the exact Core image digest of that beta. - stable promotion (
release-assets.yml, tagvX.Y.Z) → add-onftwpublishes versionX.Y.Zby re-tagging the add-on beta image whose Core digest FTW just promoted. No rebuild, same rule FTW itself follows.
Two pull requests implement this; links are in the comments below once they are up.
Why it does not work today
The add-on repository is pinned to add-on 0.1.0-beta.1 = Core v1.10.0-beta.1 (July 2026) and has not moved since 2026-08-17, while Core has shipped every beta from v2.x through v3.4.2-beta.4.
The three blockers
- The add-on image is built on the retired optimizer image.
ftw/Dockerfilethere isFROM ${FTW_OPTIMIZER_FROM}and itsrun.shstarts/opt/venv/bin/ftw-optimizer. refactor: retire Python optimizer and separate updates #1083 removed that image on 2026-09-07; the compiled Energyplan worker now ships insideghcr.io/srcfl/ftw. No add-on can be built from any Core newer than that. - The sync gate waits for evidence FTW never writes.
scripts/upstream_sync.pyrefuses a Core pin unless the GitHub release body contains alive pilotlink intosrcfl/ftw. FTW's generated release notes never carry one, so the hourlySync upstream FTWrun has loggedCore vX has no labeled live-pilot evidence; retrying laterfor four weeks. - FTW never notifies the add-on repository. Its
sync-upstream.ymlalready acceptsrepository_dispatchof typeftw-release, but nothing inbeta.ymlorrelease-assets.ymlsends it.
What the pull requests do
srcfl/ftw (small, CI only):
beta.ymlgains a final job that sendsrepository_dispatchftw-releasewithchannel: beta, the tag and the commit tosrcfl/home-assistant-addonsafter the prerelease and its digest receipt exist.release-assets.ymlsends the same withchannel: stableafter the stable release is public.- Both steps use a new secret
HA_ADDON_DISPATCH_TOKEN. When it is unset they log a notice and succeed, because the add-on repository still polls hourly. The release is never blocked by the add-on.
srcfl/home-assistant-addons (the bulk):
- Build the add-on
FROMthe pinned Core digest only. Drop the optimizer image, worker supervisor loop, Unix socket and Python health check; Core already bundles Energyplan and its Go planner fallback. - Add the
ftw-betaadd-on next toftw. Both share one image,ghcr.io/srcfl/home-assistant-addons/ftw, tagged by version. - The add-on version mirrors the Core version (
3.4.2-beta.4,3.4.2). One upstream component no longer needs a separate version line. - The sync verifies each pin against the registry (multi-arch index, revision and version labels) and against FTW's own release receipt (
ftw-image-digests.jsonfor beta,ftw-promotion-receipt.jsonfor stable) instead of a release-body regex. - Stable promotion stays a retag of the tested add-on beta digest, and stays blocked until one Home Assistant OS and Supervisor pilot is recorded in
compatibility.yaml.
Owner setup, and what is deliberately not automated
- Secret.
HA_ADDON_DISPATCH_TOKENinsrcfl/ftw: a fine-grained PAT (or GitHub App token) with Contents: read and write onsrcfl/home-assistant-addonsonly. The job-scopedGITHUB_TOKENcannot dispatch to another repository. This is repository setup, like the registry credentials in AGENTS.md, not a release step. - First stable. The add-on's stable channel only publishes after a person records a passed HA OS pilot. HuggeK has volunteered to run that pilot on the first beta built from these changes.
- Cadence. Every Core beta becomes an add-on beta. Core cut eight betas in the last five days, so
ftw-betausers will see that many update prompts. That is what a beta slug is for; the stable slug moves only when FTW promotes. - Switching channels.
ftwandftw-betaare separate Home Assistant apps with separate/data. Moving between them means restoring a backup into the other app.
Activity
HuggeK commentedon Sep 13, 2026
Both pull requests are up:
ftw-releasedispatch tobeta.ymlandrelease-assets.yml(CI-only, plus one paragraph in AGENTS.md about theHA_ADDON_DISPATCH_TOKENsecret).ftw-betaapp next toftw, and makes the sync verify pins against FTW's release receipts. It is seeded to Core v3.4.2-beta.4, so merging it publishes the first beta.Order does not matter: the app repository keeps polling hourly, and the dispatch is a no-op until the secret exists.
Testing plan after #8 merges: install FTW (beta) from the repository, run the checks in
pilot/README.md, and record the result incompatibility.yamlwith a small PR. That unlocks the stable app for the next FTW stable promotion.ci: notify the Home Assistant app repository on every release (#1238)
feat: build from Core alone and publish beta and stable apps (#8)