Skip to content

Describe the release flow as it works now #136

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
frahlg merged 1 commit into from
Sep 25, 2026
+16 −8
Merged

Describe the release flow as it works now #136

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 16 additions & 8 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,16 +105,24 @@ source commit and artifact bytes; it does not claim hardware test coverage.
## Release flow

```text
public PR -> public CI -> reviewed commit -> signed FTW beta
-> site test -> stable promotion of the exact beta commit
public PR -> public CI -> reviewed commit on main -> signed drivers-beta
-> FTW pins the commit and ships it in an FTW beta
-> FTW stable -> drivers-stable promoted
```

The FTW channel contains every catalog driver. The release build turns each
source into a separate, read-only Lua asset and checks its FTW v1 contract.
The beta workflow runs on protected `main`; stable promotion requires the exact
signed commit found in beta. Refreshing the signed catalog never installs or
activates code. FTW keeps its own safety, activation, rollback and bundled
recovery paths.
Drivers reach FTW users with the FTW release: FTW bundles the commit pinned in
its `drivers/BUNDLED_SOURCE.json`, and `ftw update` and `ftw rollback` move
those drivers with FTW. Every commit on `main` is published to the signed
`drivers-beta` channel, where an owner can pick one driver's newer version
Comment on lines +115 to +116

@chatgpt-codex-connector chatgpt-codex-connector Bot Sep 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Limit the beta publication claim to triggering commits

The release workflow does not publish every commit on main: .github/workflows/ftw-drivers-release.yml lines 3-14 has a paths filter covering driver, manifest, build-tool, and workflow files. README-only, test-only, and many other commits—including this commit itself—therefore leave drivers-beta pointing at an older SHA, so the unconditional statement is incorrect and can mislead provenance checks.

Useful? React with 👍 / 👎.

from FTW's Versions list. After a stable FTW release, `drivers-stable` is
promoted with `gh workflow run ftw-drivers-release.yml --ref main -f
channel=stable`; it accepts only the exact commit `drivers-beta` carries, and
Comment on lines +118 to +119

@chatgpt-codex-connector chatgpt-codex-connector Bot Sep 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Make the stable command target the beta commit

When main advances after the beta commit used by the FTW stable release, this command targets the new head rather than that beta commit. The workflow requires its checkout to equal current origin/main at .github/workflows/ftw-drivers-release.yml lines 46-51 and then requires the same SHA as drivers-beta at lines 73-92, so an intervening non-release commit causes the documented promotion command to fail; an intervening beta publication could instead promote a commit FTW stable did not bundle. The release step needs a way to select the exact tested beta commit, or the documentation must state and enforce the required ordering.

Useful? React with 👍 / 👎.

serves installs that read the stable channel.

The channel contains every catalog driver as its own signed Lua asset. A driver
the catalog marks `control: true` keeps its control path; every other one is
read-only. Refreshing the signed catalog never installs or activates code.
Comment on lines +123 to +124

@chatgpt-codex-connector chatgpt-codex-connector Bot Sep 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Describe the actual control predicate

The catalog flag does not determine whether a channel artifact is read-only: tools/ftw_repository.py sets controls from the presence of driver_command and the absence of DRIVER.read_only (lines 640-648). Consequently, current drivers including kstar, pixii, alphaess, solaredge, solax, varta, and deye have control: false manifests but receive write-capable channel artifacts. Saying every driver not marked control: true is read-only gives operators a false safety guarantee and obscures the required read/control distinction.

AGENTS.md reference: AGENTS.md:L17-L23

Useful? React with 👍 / 👎.

FTW keeps its own safety, activation, rollback and bundled copies.

Each asset name contains the driver ID, semantic version and source hash. FTW
downloads only the selected driver. The release workflow never replaces a
Expand Down
Loading