Repository navigation
ci: run the end-to-end suite on the Docker runtime - #91
Merged
Merged
Conversation
The acceptance scenarios in internal/server ran only on the in-memory store, which production does not use. Postgres was covered by the nine cases of the store conformance suite. The server test harness now takes its store from one place: the memory store by default, and an empty Postgres schema when DIFFERENTLY_TEST_POSTGRES_URL is set. The new postgrestest package creates that schema, migrates it and drops it when the test ends; the conformance suite uses it too, instead of dropping tables between subtests (it missed the secrets table). `make test-postgres` runs both packages against Postgres, one after the other because scheduler leadership is one advisory lock per database, and the CI job that already starts Postgres calls it. With DIFFERENTLY_TEST_POSTGRES_REQUIRED set, a missing database fails the run instead of skipping it. The whole server suite passes on Postgres (three runs in a row, with -race). It exposed no defect. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com> Signed-off-by: Jalil <reachjalil@gmail.com>
The end-to-end suite (test/e2e) drives the real stack through the public API: Postgres, differently-server and an OpenSandbox server whose sandboxes are real containers. It had only ever been run by hand; CI compiled it but never ran it. A new job builds the server image, starts the compose stack, runs the suite and prints the stack's logs if anything fails. It is not yet one of the jobs the approval waits for. `make e2e-prepare` also pulls python:3.12-slim, which two tests boot, so a slow first pull does not count against a sandbox's start. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com> Signed-off-by: Jalil <reachjalil@gmail.com>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…es' into ci/e2e-on-docker-runtime
The verification ladder, the e2e README and the changelog said the suite is run by hand. They now name the CI job, and the e2e README records its first run: 16 passed and 2 skipped on a GitHub-hosted x86_64 runner. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com> Signed-off-by: Jalil <reachjalil@gmail.com>
The job passed on two runs in a row on this pull request (16 passed, 2 skipped, about two minutes each), so it joins the jobs the CI approval needs. A change that breaks the real stack no longer gets approved. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com> Signed-off-by: Jalil <reachjalil@gmail.com>
reachjalil
marked this pull request as ready for review
November 11, 2026 00:50
…er-runtime Signed-off-by: Jalil <reachjalil@gmail.com> # Conflicts: # CHANGELOG.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
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 is this about?
CI runs the end-to-end suite on every pull request, and the CI approval waits for it.
It was stacked on #90, which is merged; this branch now holds
pre-releaseand differs from it only by the end-to-end job and its docs.What problem does it solve?
test/e2edrives the real stack through the public API: Postgres,differently-serverand an OpenSandbox 1.2.0 server whose sandboxes are real containers. It had only ever been run by hand, and not at all forv0.1.0-alpha.3; CI compiled it but never ran it. A change could break the real stack and still be approved.How is it implemented?
end-to-end (docker runtime):make e2e-prepare e2e-up e2eon a GitHub-hosted runner, the stack's logs on failure, andmake e2e-downalways. 30-minute limit.approve when CI passesjob now needs it.make e2e-preparealso pullspython:3.12-slim, which two tests boot, so a slow first pull does not count against a sandbox's start.test/e2e/README.md,docs/maintaining.mdandCHANGELOG.mdsay CI runs the suite and record the first run.How was it tested?
By this pull request's own runs, on Ubuntu 26.04 x86_64:
pre-releasewith #90TestDesktopStreamsneeds a desktop image,TestIdlePauseAndWakeThroughPortURLa microVM pool.v0.1.0-alpha.3(the reconciler, TTL backstop, scheduler and audit changes included) and the first on x86_64 with the Docker runtime. It found no failure.e2eback out of the approval'sneeds.Checklist
make verifypasses (no Go code changed;npm run buildinsite/passes)git commit -s)api/openapi.yaml, both SDKs anddocs/feature-parity.md(no API change)🤖 Generated with Claude Code