dotCMS / dotCMS/core

CI: rebalance integration and Postman shards to cut PR wall clock

Open
#36,942 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Team : Maintenance Type : Task
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:

  1. GraphQLTests is 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.
  2. The build-classes artifact is uploaded on every build and consumed by nothing. It costs ~0.5m on the serial critical path. The only restore-classes: true caller is deploy-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 GraphQLTests by folder rather than splitting the 518KB collection file.
  • Merge the Postman micro-groups that are ~85% fixed overhead.
  • Delete the dead build-classes artifact.
  • 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.