Speed up e2e(core) suite with Ginkgo procs and concurrent waits - #6070
Merged
Merged
Conversation
Run the core test suite across 4 Ginkgo processes in CI instead of serially. The 8-core runner has capacity to spare, and the ~30 core specs are independent enough to distribute safely. Two issues blocked parallelism: - Four test files named servers using only GinkgoRandomSeed(), which is identical across all procs; concurrent processes would attempt to create the same Docker container name. Switch to GenerateUniqueServerName which includes the OS PID (unique per proc). - ExpectMCPServersRunning polled workloads sequentially; specs that start 4 containers (group_rm "delete with workloads") paid the full sum of readiness waits. Replace the serial loop with concurrent goroutines so the wait is bounded by the slowest workload, not the sum. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
ChrisJBurns
requested review from
JAORMX,
amirejaz,
aponcedeleonch,
jhrozek,
rdimitrov and
reyortiz3
as code owners
July 27, 2026 22:40
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6070 +/- ##
==========================================
+ Coverage 72.18% 72.20% +0.01%
==========================================
Files 721 721
Lines 75062 75062
==========================================
+ Hits 54183 54196 +13
+ Misses 17017 17005 -12
+ Partials 3862 3861 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
reyortiz3
approved these changes
Jul 27, 2026
3 tasks
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.
Summary
GinkgoRandomSeed(), which is identical across all Ginkgo procs — concurrent processes would collide on the same Docker container name. Those are switched toGenerateUniqueServerNamewhich embeds the OS PID.ExpectMCPServersRunningpreviously polled workloads one at a time; specs that start 4 containers paid the full sum of readiness waits. Goroutines + WaitGroup make the wait concurrent (bounded by the slowest, not the sum), benefiting both single- and multi-process runs.Type of change
Test plan
procs: 4matrix field will be exercised on the next CI rungo build ./test/e2e/...andgo vet ./test/e2e/...pass locally with the changesPROCSdefaults to1for all other test matrix entries, so no other suite behaviour changesSpecial notes for reviewers
--procs=Nin Ginkgo v2 spawns N independent OS processes, each with its ownBeforeSuite/AfterSuite. Core specs use the real Docker daemon with no per-process config isolation, so unique container names are the only required safety property — whichGenerateUniqueServerName(PID + nanosecond timestamp + random seed) guarantees.The
procsmatrix field is absent from all other suites, so they receivePROCS=1(sequential) and are unaffected.Generated with Claude Code