Repository navigation
ci(e2e): run core in the stack and load pinned drivers from the build farm - #550
Merged
Merged
Conversation
… farm The e2e stack had no core, so nothing in it could run a driver and the specs that bind module state (the home availability panel, room check-in) could only be guarded. core is now part of the stack, started after init has created the tables it subscribes to, with its binaries coming from the PlaceOS build farm the way every deployment's do. The seed creates a repository row and driver rows for Place::Bookings and the demo calendar (PlaceOS/drivers#639), pinned to a commit so the farm builds each CPU architecture once, and waits until core holds the binaries before bring-up returns. Helpers for logic modules and module state go with it, for the specs that attach the drivers to rooms. The runner needs build.placeos.run and the drivers S3 bucket reachable.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
This was referenced Oct 7, 2026
- Move the drivers repository row to the configured uri and branch. - Replace a room's module from an earlier driver instead of adding a second one. - Retry /compiled on network errors, and ignore build output left by an earlier attempt. - Re-check the search-backed driver listing before creating a row. - Log a warning when drivers do not load, so a build farm outage does not fail every spec. - Share the listing helpers through e2e/support/api.ts and type the rows. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Deployment failed for project frontend-templates with the following error: Learn More: https://vercel.com/placeos?upgradeToPro=build-rate-limit |
# Conflicts: # .github/workflows/e2e-advisory.yml # e2e/README.md # e2e/stack/SELF_HOSTED_RUNNER.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The e2e stack now runs core, so it can run drivers, and the seed loads two of them from PlaceOS/drivers:
Place::Bookingsand the new demo calendar it polls (PlaceOS/drivers#639). That is what the workplace home page's availability panel and room check-in bind (Bookings/status), and until now neither could be tested because nothing in the stack ever reported a status.e2e/stack/docker-compose.yml: acoreservice with its owncore-driversvolume. Binaries come from the PlaceOS build farm, the way every deployment's do;E2E_BUILD_URLoverrides the farm andCLUSTER_NAMEidentifies the stack in its logs.e2e/stack/up.sh: core starts afterinit. It subscribes to the driver and module tables as it starts, and a core that comes up before the migrations exist keeps answering HTTP while never managing a driver again. Found the hard way on the first cold start.e2e/support/drivers/: the pinned driver catalogue (drivers.env.ts), engine API helpers for repositories, drivers, logic modules and module state (drivers.api.ts), and the bring-up step that creates the rows and waits until core holds the binaries (drivers.seed.ts).seed.tsruns it last, so the wait on the farm happens once at bring-up and never inside a spec's timeout.e2e/README.md, the runner's outbound host list inSELF_HOSTED_RUNNER.md, the workflow comment.Why pin a commit
The farm keys a binary on repository, branch, commit, file and CPU architecture, and compiles a key it has not seen on the first request. Pinned, that is one compile per architecture ever (both are already built for the pinned commit: the Intel runner downloads, it does not wait).
HEADwould make core force a rebuild on every bring-up. To run the suite against a drivers branch, setE2E_DRIVERS_URI,E2E_DRIVERS_BRANCHandE2E_DRIVERS_COMMITbeforeup.sh.Until PlaceOS/drivers#639 merges the pin points at its branch. After it merges,
drivers.env.tsneedsbranch: 'master'and the squash commit; that is a two-line change and this PR should not merge before it is made.What uses it
On #497 (Sharmila's branch),
room.seed.tsnow attaches a Calendar and a Bookings module to every seeded room and waits for the status,up.shruns it at bring-up, and the HOME-10 guard is lifted: the panel lists the seeded room and its button opens the booking modal, which is the whole chain working (driver process, redis, the rest-api websocket, the app). ROOM-23 (room check-in) binds the same module and is now only unwritten rather than blocked.Verified
up.sh --freshbrings core up, the seed creates both driver rows, core fetches the binaries from the farm (drivers_place_bookings_635d0a1_arm64,drivers_place_demo_calendar_635d0a1_arm64in the volume), and 12 rooms get their modules reportingfreein 45 s.Stacked on #549 (same bring-up script); the base moves to develop when that merges.