build: FTW holds no driver source - #712
Conversation
drivers/*.lua leaves git and is gitignored. The files still ship -- offline recovery needs them in the image, the release tarballs carry them, the tests read them -- but they are fetched from the commit pinned in drivers/BUNDLED_SOURCE.json rather than committed here. The point is not the bytes. It is that there is no file to open a pull request against. Two contributors spent real effort, including thirty minutes on an SE17K and register-by-register probing on a Pixii, writing fixes against files that regenerate. A guard that fails the pull request recovers the codebase but not the afternoon. Absence teaches faster than a red check does. Everything that needed the files in git already stopped needing them: #708 made the fetch a build step and proved a build works from the pin alone, #709 moved the SemVer gate onto the pins. This is the small change those two were for. --check changes its question. It used to compare committed bytes against the pin; there are no committed bytes now, so it asks whether any driver is committed at all. Cheaper than a content diff, a stricter rule, and it needs no network. Every workflow that reads drivers/ fetches first: core, drivers and e2e in test.yml, the image build in beta.yml, and both the tarball and image jobs in release-assets.yml. e2e, release and driver-repository-validate depend on drivers-present locally, so a missing fetch fails with the remedy rather than a confusing file-not-found. Verified: rm -rf the drivers, make drivers restores 37 of 37, go test ./... passes uncached, and the full-stack e2e is green. The guard is proven to fire -- git add -f on one driver and --check reports it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: Fredrik Ahlgren <fredrik@sourceful-labs.com>
![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: bf3c1d4cc3
ℹ️ 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".
| ```bash | ||
| make drivers | ||
| ``` |
There was a problem hiding this comment.
make dev
On a fresh clone, the documented local-development sequence still goes directly from git clone to make dev, but that target has neither a drivers nor drivers-present prerequisite. Because config.local.example.yaml references drivers/ferroamp.lua and drivers/sungrow.lua, both files are absent after this change and the simulator drivers cannot load, leaving the advertised development stack without telemetry; wire this fetch or at least the presence guard into make dev.
AGENTS.md reference: AGENTS.md:L89-L95
Useful? React with 👍 / 👎.
| echo "no driver source is committed here (drivers/ is fetched from the pin)" | ||
| exit 0 |
There was a problem hiding this comment.
When a driver is later removed from BUNDLED_SOURCE.json, an already-populated checkout retains its ignored .lua file: the normal fetch only copies listed drivers, while this new --check path exits before the existing unlisted-file scan. Git cannot report the stale ignored file, and drivers-present accepts any single Lua file, so make release can archive and ship a driver that was explicitly removed from the recovery set; the fetch should delete unlisted files or release validation should compare the complete directory with the pin.
AGENTS.md reference: AGENTS.md:L12-L15
Useful? React with 👍 / 👎.
1 participant
The cutover.
drivers/*.lualeaves git and is gitignored.The files still ship. Offline recovery needs them in the image, the release tarballs carry them, the tests read them. They are fetched from the commit pinned in
drivers/BUNDLED_SOURCE.jsonrather than committed here.Why, in one paragraph
The point is not the bytes. It is that there is no file to open a pull request against. Two contributors spent real effort — thirty minutes on an SE17K, register-by-register Modbus probing on a Pixii — writing fixes against files that regenerate. A guard that fails the pull request recovers the codebase but not the afternoon. Absence teaches faster than a red check does.
This is the small change #708 and #709 were for
Everything that needed the files in git already stopped needing them:
What changed
--checkasks a different question. It used to compare committed bytes against the pin. There are no committed bytes now, so it asks whether any driver is committed at all — cheaper than a content diff, a stricter rule, and it needs no network.Every workflow that reads
drivers/fetches first:test.ymldrivers-from-pinalready did)beta.ymlrelease-assets.ymlLocally,
e2e,releaseanddriver-repository-validatedepend ondrivers-present, so a missing fetch fails with the remedy rather than a confusing file-not-found.Verified
The guard is proven to fire:
git add -f drivers/pixii.luamakes--checkreportCOMMITTED drivers/pixii.luaand exit 1.Pin is at device-drivers
a4d0205, current with its main.The one thing to watch
The release workflows cannot be exercised by this pull request — they run on tags. I read
beta.yml,release-assets.yml,release.yml,optimizer-release.ymlandrpi-image-build.ymland added the fetch to every job that either builds the image or packs the tarballs; the other two never touchdrivers/. Worth a deliberate look before the next release, since a missed fetch there produces an image with no drivers rather than a failed build.🤖 Generated with Claude Code