From 27 minutes to 4: Cutting CI build time by 85%
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
A developer documents cutting the CI build time of their open-source Scala expense-tracker from 27 minutes to about 4 minutes, roughly 85%. The biggest wins came from sharing one Postgres test container across the run, booting one app per test suite instead of per test, skipping work for unaffected code…
Score
0.67total under rubric v2.0Contestedjudges differ by 0.45 on new information
- Significance0.43
- Reader interest0.75
- Audience breadth0.67
- Practical relevance0.90
- Substantiated0.85
- Technical depth0.83
- New information0.78
- Counts against: Promotional0.11
- Counts against: Overclaim0.14
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| Significance | 0.51 | 0.30 | 0.48 | 0.43 | 0.20 | +0.25 | +0.107 |
| Reader interest | 0.74 | 0.70 | 0.82 | 0.75 | 0.12 | +0.20 | +0.151 |
| Audience breadth | 0.78 | 0.60 | 0.63 | 0.67 | 0.18 | +0.10 | +0.067 |
| Practical relevance | 0.98 | 0.80 | 0.90 | 0.90 | 0.18 | +0.15 | +0.134 |
| Substantiated | 0.96 | 0.70 | 0.88 | 0.85 | 0.26 | +0.10 | +0.085 |
| Technical depth | 0.97 | 0.75 | 0.78 | 0.83 | 0.23 | +0.10 | +0.084 |
| New information | 0.90 | 0.50 | 0.95 | 0.78 | 0.45 , above the contested threshold | +0.10 | +0.078 |
| Promotional | 0.06 | 0.20 | 0.08 | 0.11 | 0.14 | −0.15 | −0.017 |
| Overclaim | 0.16 | 0.20 | 0.06 | 0.14 | 0.14 | −0.15 | −0.021 |
| Sum of contributions | +0.667 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.667 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
Claim check
Claim check: 4 matches source · 2 no source given · 2 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenNumber
The expense-tracker project's CI execution time grew to 27 minutes per run and was reduced to an average of 4 minutes.
The article gives no link or citation for it.
The article says “the CI execution time grew to 27 minutes per run! Of course this is an annoying bottleneck. With some effort I managed to get this down to an average of…”
The source says No source to compare with.
Couldn’t checkNumber
Switching from one Postgres container per test to one shared container for the whole run saved about 15 minutes.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “I switched from launching a container per test to one shared container for the whole run (amazing result, 15 minutes saved”
The source says No passage could be compared.
Source cited by the article: github.com/AlexITC/expense-tracker/pull/22
Matches sourceNumber
Booting one Play app per suite instead of per test cut about 70 seconds from the server test step (183s to 113s).
The cited source says the same thing.
The article says “Booting one app per suite instead of per test was trivial and cut ~70 seconds”
The source says “Before (`GuiceOneServerPerTest`) | ~183s | | After (`GuiceOneServerPerSuite`) | ~113s”
Source cited by the article: github.com/AlexITC/expense-tracker/pull/27
Matches sourceNumber
Running the tests in parallel saved about 43 seconds on the server test step (122s to 79s).
The cited source says the same thing.
The article says “Running the test suite in parallel saved another 40 seconds”
The source says “35% faster on the 4-core runner (test step 122s→79s”
Source cited by the article: github.com/AlexITC/expense-tracker/pull/37
Matches sourceNumber
Using real bcrypt at the cheapest cost setting in tests saved about 25 seconds on the HTTP-level test suite (59s to 34s).
The cited source says the same thing.
The article says “I kept real bcrypt in the tests but used the weakest cost setting, saving ~25 seconds without faking the hashing”
The source says “10 (before) | 59s | | 4 (after) | 33–34s | **~25s faster** on the Play specs”
Source cited by the article: github.com/AlexITC/expense-tracker/pull/38
Couldn’t checkCausal conclusion
A cache step in the CI workflow ran but never persisted its cache because every save failed, so runs repeated work that should have been skipped.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “So the cache was never persisted; every run re-did the work it was supposed to skip”
The source says No passage could be compared.
Source cited by the article: github.com/AlexITC/expense-tracker/pull/33
Matches sourceGeneralization
On GitHub Actions, a cache saved on a PR branch is only visible to that PR, not to main or other PRs.
The cited source says the same thing.
The article says “on GitHub Actions a cache saved on a PR branch is only visible to that PR, not to main or other PRs”
The source says “When a cache is created by a workflow run triggered on a pull request, the cache is created for the merge ref (refs/pull/.../merge). Because of this, the cache will have…”
Source cited by the article: docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching
No source givenNumber
The end-to-end CI improvement was from about 27 minutes to about 4 minutes, roughly 85%.
The article gives no link or citation for it.
The article says “the end-to-end result is ~27 min -> ~4 min (~85%”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 3 pts, not on front page
Recorded for context only, checked 24 Oct 2026, 08:54 UTC. It played no part in the ranking.