chore: remove the Raspberry Pi image - #1393
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f571c2566d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| name: verify complete draft assets | ||
| runs-on: ubuntu-latest | ||
| needs: [meta, binaries, imager-metadata] | ||
| needs: [meta, binaries] |
There was a problem hiding this comment.
When this workflow resumes a draft created by the previous workflow, that draft can already contain os_list.json because the old imager-metadata job uploaded it before assets-ready. The new workflow leaves that asset in place, while check-stable-release.py now requires exactly nine assets and rejects os_list.json as unexpected, so any interrupted stable publication that reached the metadata upload can no longer be resumed using the required master workflow. Delete the legacy asset during resume or explicitly accept it for existing drafts.
AGENTS.md reference: AGENTS.md:L238-L242
Useful? React with 👍 / 👎.
| | External automation and agent access | Give authorized clients structured analysis data, schedule/goal changes and proposed-plan submission. Temporary external control expires; durable goals persist. Support local access and secure cloud MCP access. | Paired Core/client contract tests cover permissions, expiry, replay, rejection, revocation and reconnect. An agent can trace a request through to measured outcome. Prove local fallback when the caller disappears. Reuse the session/relay where suitable and verify that relay and escrow remain blind. Cloud MCP is a target, not a claim of a shipped endpoint. | | ||
| | Less configuration, reliable operation | Every normal setting serves a user need. Keep expert controls discoverable. Installation, updates, backup and recovery remain part of the finished experience. | Audit settings and feature use before removal. Test migration of stored choices so hidden settings cannot keep directing behaviour. Verify restart, upgrade and restore on a target box and review affected UI flows. | | ||
| | Updates the owner runs | The owner operates the host; FTW supplies the steps. `ftw update` runs unattended, falls back on its own when a new release does not stay up, and makes a verified full backup before a change to stored data. The same steps are API calls, so owners and their agents can wrap them. On native, the web UI shows the version and the release notice only. The installer, the Pi image and the Docker migration produce one native layout. | The evidence list in [ADR 0007](adr/0007-self-updating-binary.md#evidence-required-before-rollout), on the home box and one other site: update and rollback timings, a crash during and just after the trial, a slow first start, a state-schema change and its way back, an unattended run, disk use after ten updates, a freshly flashed Pi image, and a Docker 2.x or 3.x box moved to native with a tested return to its old installation. | | ||
| | Updates the owner runs | The owner operates the host; FTW supplies the steps. `ftw update` runs unattended, falls back on its own when a new release does not stay up, and makes a verified full backup before a change to stored data. The same steps are API calls, so owners and their agents can wrap them. On native, the web UI shows the version and the release notice only. The installer and the Docker migration produce one native layout. | The evidence list in [ADR 0007](adr/0007-self-updating-binary.md#evidence-required-before-rollout), on the home box and one other site: update and rollback timings, a crash during and just after the trial, a slow first start, a state-schema change and its way back, an unattended run, disk use after ten updates, a freshly flashed Pi image, and a Docker 2.x or 3.x box moved to native with a tested return to its old installation. | |
There was a problem hiding this comment.
This row now says only the installer and Docker migration produce the native layout, but its acceptance evidence still requires testing “a freshly flashed Pi image.” Since this commit deletes the image builder and Imager listing, that evidence can no longer be produced and the maintained roadmap contradicts the new product direction; replace it with evidence from a freshly prepared Raspberry Pi OS host using the installer.
AGENTS.md reference: AGENTS.md:L133-L135
Useful? React with 👍 / 👎.
FTW no longer builds its own Raspberry Pi image. A Pi runs Raspberry Pi OS Lite 64-bit with the installer, or FTW in Docker, like any other host. Removes deploy/pi-gen, the Imager listing template, the monthly image workflow and its guide. The old 2.x stable workflow no longer mirrors Imager metadata onto a release, and its asset guard and tests follow. ADR 0007 decision 6 now says there is no image. Cards flashed from the old image keep Docker 2.x until the guided migration. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MuerPFZFG88kgu8sWVHeq7
f571c25 to
a727bf2
Compare
1 participant
Why
The owner decided FTW should not have its own Raspberry Pi image. A Pi is a host like any other: Raspberry Pi OS Lite 64-bit with the installer, or FTW in Docker. The monthly image still installed Docker 2.x with the sidecar, so new Pi users kept arriving on the old line.
What
deploy/pi-gen/,deploy/imager/os_list.json,.github/workflows/rpi-image-build.ymlanddocs/rpi-image.md, plus the.gitignoreentries for pi-gen.release-assets.ymlis the exceptional old 2.x stable path. It no longer mirrors the Imageros_list.jsononto a release.scripts/check-stable-release.pystops requiring that asset, andscripts/test-exact-image-promotion.shfollows: no Imager assertions, and five release-token uses instead of six.docs/operations.md,docs/self-update.mdand the setup-guide index lose their links to the image guide. The setup guides themselves stay: they prepare a stock Raspberry Pi OS card with Raspberry Pi Imager.Dockerfileanddocker-compose.ymlno longer point at pi-gen.Also
docs/native-beta.md. The stalev0.131.0-beta.1command frommasteris replaced by an exact-tag install.rpi-installerrelease is deleted (owner decision). It holds the 2.x image and the Imageros_list.jsonthatdocs/rpi-image.mdpointed Imager at. Cards already flashed keep Docker 2.x until the guided migration.Evidence
bash scripts/test-exact-image-promotion.shpasses, and passes onmasterbefore the change.make release-workflow-test compose-migration-test container-boundary-testpasses.bash .github/scripts/test-change-classifier.shpasses.release-assets.ymlparses as YAML.🤖 Generated with Claude Code
https://claude.ai/code/session_01MuerPFZFG88kgu8sWVHeq7