Repository navigation
Allow extensions/globals.Reset to support re-running RunSpecs - #1673
Merged
Merged
Conversation
Programs that drive Ginkgo programmatically — merged test binaries for large monorepos, meta-testing of dynamically generated suites — want to run several suites sequentially in one process: register specs, call RunSpecs, Reset, register the next suite's specs, and call RunSpecs again. Everything RunSpecs uses is already either reconstructed per run (reporter, output interceptor, parallel client, progress handler) or reset by extensions/globals.Reset (the suite and failer themselves). The one blocker is the suiteDidRun guard, which lives in package ginkgo where Reset cannot reach it, so a second RunSpecs always exits with GinkgoErrors.RerunningSuite. Move the flag into internal/global as SuiteDidRun and clear it in InitializeGlobals. Calling RunSpecs twice without an intervening Reset still fails exactly as before — only an explicit Reset arms a fresh run.
Contributor
Author
|
Shout if you need more info on this, I'm hoping it should be an easy one 🙏 |
Owner
|
wow what a trivial but impactful change. Do you mind updating (or asking a robot to update) the long-form docs as well? I'll pull this in for now but a follow-on PR for the docs would be much appreciated. |
Contributor
Author
|
Getting a docs PR prepared now, thank you for being so responsive! |
Contributor
Author
|
Docs here: #1674 |
onsi
pushed a commit
that referenced
this pull request
Jun 11, 2026
Follow-up to #1673, covering the extensions/globals.Reset + RunSpecs pattern in the long-form docs: when it applies, how each run behaves, and the caveats (never Reset inside a running suite; Ginkgo resets its state but not yours; parallelism stays one process per worker).
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.
Closes #1672.
What
Programs that drive Ginkgo programmatically (merged test binaries for large monorepos, meta-testing of dynamically generated suites) want to run several suites sequentially in one process: register specs, call
RunSpecs,Reset, register the next suite's specs, and callRunSpecsagain.Everything
RunSpecsuses is already either reconstructed per run (reporter, output interceptor, parallel client, progress handler) or reset byextensions/globals.Reset(the suite and failer themselves). The one blocker is thesuiteDidRunguard, which lives in packageginkgowhereResetcannot reach it, so a secondRunSpecsalways exits withGinkgoErrors.RerunningSuite.This moves the flag into
internal/globalasSuiteDidRunand clears it inInitializeGlobals. CallingRunSpecstwice without an interveningResetstill fails exactly as before — only an explicitResetarms a fresh run, preserving the accidental-rerun protection. Includes a test inextensions/globals.Why we want it
At incident.io we compile ~690 monorepo suites into one generated test binary (each per-suite binary was ~350MB of near-identical bytes). With this change, CI worker processes drain a suite queue —
Reset, re-register,RunSpecs— paying process boot once per worker instead of once per suite. Per-suite reporting (--ginkgo.junit-reportet al) behaves identically to separate processes, and our test phase dropped from ~98s to ~47s. We're currently running this in production CI from a fork pinned viareplace, and would love to drop the fork.