CI: rebalance integration and Postman shards to cut PR wall clock
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 970
- Forks
- 486
- Avg merge
- 3d 33m
- Merged PRs (30d)
- 170
Description
Problem
A PR pipeline run takes 74–103m of wall clock. The structural floor is ~54m:
Initial Artifact Build 15m (serial prefix -- every test job waits on it)
slowest test job 39m
----
floor 54m
Everything above that floor is queue time (one run fans out ~26 jobs / ~587 job-minutes; one observed run accumulated 271 job-minutes of queue, with individual jobs waiting 20m).
The floor itself is set by the slowest single test job, and two jobs were tied at the top:
| shards | test time | max shard | ideal (balanced) | |
|---|---|---|---|---|
| Integration | 7 | 130.8m | 38.9m (MainSuite 1a) | 26.5m |
| Postman | 11 | 147.8m | 37.8m (GraphQL) | 22.8m |
Because they are nearly equal, rebalancing either one alone moves wall clock by ~1 minute — the other immediately becomes the tail. They have to be fixed together.
Two further findings from measuring:
GraphQLTestsis a single 25.6m collection. With ~9.4m of fixed cost per Postman shard, no amount of regrouping gets Postman below ~35m. It is the binding constraint on the entire pipeline.- The
build-classesartifact is uploaded on every build and consumed by nothing. It costs ~0.5m on the serial critical path. The onlyrestore-classes: truecaller isdeploy-javadoc, which no workflow invokes.
Scope
- Rebalance integration shards on measured per-class time rather than class count (class count is a poor proxy — one shard held 298 classes/31m, another 52 classes/14m).
- Rebalance Postman groups on measured newman time, and shard
GraphQLTestsby folder rather than splitting the 518KB collection file. - Merge the Postman micro-groups that are ~85% fixed overhead.
- Delete the dead
build-classesartifact. - Hold total job count flat so this does not add queue pressure.
Out of scope
Queue time — the dominant term above the 54m floor. Reducing it needs either runner capacity or fewer jobs, and is worth measuring separately once the tail is down.
Acceptance
- Slowest test job drops from ~39m to ~26m.
- Total job count unchanged.
- No test is dropped, duplicated, or silently skipped.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the CI workflow definitions for the integration and Postman shards, then trace the build-classes artifact and its only named consumer, deploy-javadoc. Rebalance using the measured test times and verify that the slowest job is about 26 minutes, job count stays unchanged, and no tests are dropped, duplicated, or skipped.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, postman
- Domain
- build-system, ci-cd, testing-qa
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100