5 exercises on the language of running tests in continuous integration — gating merges, green and red builds, triggers, parallelisation and flaky-test retries.
Key patterns
gate the merge → require a passing check
break / fix the build → red vs green
run on every push → automatic triggers
parallelise / shard tests → cut runtime
retry / quarantine flaky tests
0 / 5 completed
1 / 5
A team lead configures the pipeline: "We’ll add a required status check so failing tests ___ the merge — you can’t merge until CI is green." Which verb is the standard collocation?
Gate the merge — the CI gatekeeping collocation:
To gate a merge means to make it conditional on a required check passing — tests, linting, review approval. The pull request literally cannot be merged until the gate is satisfied.
"gate the merge on green CI"
"a merge gate" / "a required status check"
"quality gate" — a broader threshold (coverage, security scan) that must pass
"block the merge" — near-synonym
Platform features: GitHub branch protection rules with required checks, GitLab merge request pipelines, "require status checks to pass before merging". Gating is what turns CI from advisory into enforced — it prevents a red build from ever reaching the main branch.
2 / 5
A developer apologises in chat: "Sorry, my last commit ___ the build — I forgot to update a test and now main is red." Which verb fits?
Break the build — the everyday CI failure idiom:
To break the build means to push a change that makes CI fail — tests fail, compilation errors, or a lint check trips — turning the pipeline red.
"break the build" / "you broke the build"
"the build is broken / red"
"fix the build" — get it back to green
"don’t break the build" — a team norm
Green vs red:
a green build — all checks pass
a red build — one or more checks fail
"Build is green, ship it" is classic CI culture. Note the contrast: you pass tests but you break (or fix) a build — the verb depends on the noun.
3 / 5
Setting up automation, a DevOps engineer says: "The pipeline should ___ on every push and pull request, not just on a nightly schedule." Which phrasing is most natural?
Run on every push — the CI triggering collocation:
Continuous integration means tests run automatically whenever code changes. The natural phrasing pairs the verb run with a trigger:
"run on every push" / "run on every commit"
"trigger on a pull request" / "run on PR"
"run on a schedule / nightly" (cron)
"kick off a pipeline" / "the push triggers the workflow"
Config vocabulary: in GitHub Actions you set on: [push, pull_request]; the events are triggers. "Run on every push" expresses the core CI promise: no manual step, every change is verified. "Do/make on every push" are not idiomatic — tests and pipelines run.
4 / 5
To speed up a slow suite, an engineer suggests: "Let’s ___ the tests across four runners so they execute at the same time instead of one after another."
Parallelise the tests — the CI speed collocation:
To parallelise (US: parallelize) tests is to split them across multiple workers so they run concurrently, cutting total wall-clock time.
"parallelise the test suite"
"shard the tests across N runners" — split into shards/buckets
"run tests in parallel"
"a CI matrix" — run across versions/OSes simultaneously
The opposite: tests that run serially / sequentially (one after another) are slower but simpler. Beware: parallel tests must be isolated — shared state or order dependence between them surfaces as flakiness when they suddenly run at the same time. Distractors: serialise is the opposite; compile and deprecate are unrelated operations.
5 / 5
A pragmatic CI policy reads: "For known-flaky suites, automatically ___ ___ up to three times before marking the job failed." Which phrase completes it?
Retry flaky tests — the pragmatic CI mitigation:
A flaky test fails intermittently for non-deterministic reasons (timing, network, shared state). A common stopgap is to retry it automatically — if it passes on a re-run, the job continues.
"retry flaky tests" / "auto-retry on failure"
"set retries: 3" / "re-run failed jobs"
"quarantine a flaky test" — move it out of the gating suite so it can’t block merges
Important caveat: retrying hides flakiness rather than fixing it — a retried test that keeps passing on the second try is still a real signal of a problem (a race condition or a leaky fixture). Teams retry to keep the pipeline moving but should still investigate and stabilise the underlying cause. "Delete" or "skip" loses coverage entirely; the standard CI verb here is retry.