Repository navigation
Conversation
Use hosted Ubuntu runners and local Turbo cache for the existing four-shard kitchen-sink job. Keep the native runner, browser setup, tests, and retries unchanged.
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.
Run the existing kitchen-sink Studio browser suite in the endformdev fork on portable GitHub-hosted Ubuntu runners. Upstream self-hosted runners and remote Turbo-cache secrets are unavailable here, so the fork-only workflow uses ubuntu-24.04 and local Turbo caching. It preserves native Playwright, relevant dependency builds, fixture and Chromium installation, four shards, one worker per shard, and CI retries of two.
The selected scope is 335 Chromium cases in 57 kitchen-sink browser spec files. Separate Studio base-path, docs and non-browser E2E jobs are outside this benchmark. Each job reports four cores and about 15 GiB memory. Node is 24.18.0 and pnpm 11.21.0.
Tested baseline commit:
acd0ca604383413038e22ba87dfa6088d879a878.Attempt 1 failed workflow persistence at
agents/$agentId/stream.spec.ts:116; it passed in the rerun without changing assertions. The two attempts are a small sample, not a stable benchmark. Test-stage time uses the earliest shard test-step start through latest completion, rather than summing parallel steps. Summed GitHub runner consumption was 56m08s then 50m16s. Attempt 1 dependency setup was 95–98s per shard, build 269–282s, fixture/browser setup 12–13s, with roughly 26s initial startup/discovery inside each test step. Scheduling and cache timing differed in attempt 2.Stacked Endform PR #2 preserves this baseline and documents all completed experiments. Its latest implementation runs isolated local applications on the Endform CLI host and proxies browser traffic back, with warm reuse for successful ordinary cases. A local 10-core/32-GiB Mac run completed in 4m54s with 31 failures: that is a provisional timing result, not passing or equivalent CI proof. On the standard four-core CI host, eight warm apps took 18m40s for tests with 37 failures, and 32 warm apps took 11m55s with 83 failures. These runs account for the same 335 cases and 35 skips. The migration is not green and the CI sub-five-minute target remains unmet; PR #2 records resources, remaining failures and the historical October 1 experiments.
Leave this baseline PR unmerged. The Endform PR targets this branch to isolate the migration diff. Other upstream workflows requiring self-hosted runners are outside the selected portable browser workflow. No upstream PR, force-push or unrelated settings changes were made.