Skip to content

CI: add path-scoped Windows C++ smoke gates to improve UT coverage and feedback time#11170

Open
tangkelu wants to merge 1 commit into
bambulab:masterfrom
tangkelu:ci/windows-ut-gate
Open

CI: add path-scoped Windows C++ smoke gates to improve UT coverage and feedback time#11170
tangkelu wants to merge 1 commit into
bambulab:masterfrom
tangkelu:ci/windows-ut-gate

Conversation

@tangkelu

@tangkelu tangkelu commented Jun 16, 2026

Copy link
Copy Markdown

Problem

This PR targets two concrete PR quality-gate problems in the fork:

  1. some libslic3r changes could be merged without relevant PR-time UT / smoke validation
  2. the Windows C++ UT gate was too slow when treated as one monolithic lane, so feedback was not fast enough for normal PR review

The goal of this PR is to improve both coverage and feedback time, without changing production business behavior for the sake of testing.

Approach

This PR does not split code artificially just to make tests pass faster.

Instead, it follows two rules:

  • split production/test surfaces only along real architectural and dependency boundaries
  • route changed files to the smallest relevant smoke targets, so unrelated UT work is skipped

In parallel, Windows dependency compilation is separated into a reusable prebuild workflow so PR-time smoke runs do not need to rebuild third-party dependencies each time.

Before / after

Before

Before this change, the Windows C++ smoke lane behaved largely as one large validation pass.

Representative full run:

Result:

  • started: 2026-06-09T09:13:31Z
  • completed: 2026-06-09T10:15:29Z
  • total duration: about 1h 2m

That run built the full smoke surface sequentially, including:

  • config
  • placeholder parser
  • gcode writer / reader
  • model assembly
  • filament mapping
  • apply / validate
  • perimeters
  • process math
  • process core
  • object layers
  • adhesion
  • fill
  • support material
  • trianglemesh geometry

This provided coverage, but the PR feedback loop was still too long.

After

After this change, the gate is split into:

  1. a reusable Windows dependency prebuild lane
  2. path-scoped Windows C++ smoke targets

Representative dependency prebuild run:

Result:

  • started: 2026-06-04T08:22:56Z
  • completed: 2026-06-04T09:24:15Z
  • total duration: about 1h 1m

A newer representative push-triggered deps run on the updated workflow:

Result:

  • completed successfully on 2026-06-16
  • total duration: about 50m 35s

Representative full Windows C++ smoke run after the workflow/runtime fixes:

Result:

  • started: 2026-06-16T09:22:28Z
  • completed: 2026-06-16T10:15:08Z
  • total duration: about 52m 57s

This full run completed successfully and built / ran the whole smoke surface, including:

  • config fast
  • placeholder parser
  • gcode writer
  • gcode reader
  • model assembly
  • print filament mapping
  • print apply / validate
  • print perimeters
  • print process math
  • print process core
  • print object layers
  • print adhesion
  • fill
  • support material layers
  • support material
  • trianglemesh geometry

Practical effect

So the quality gate changes from:

  • before: one large Windows C++ smoke lane with long feedback time
  • after: reusable dependency prebuild + path-scoped smoke routing

This improves the gate in two ways:

  • restores PR-time UT / smoke coverage for important libslic3r change areas
  • reduces unnecessary rebuild/rerun work by only executing the smoke targets relevant to the changed paths

Even for full smoke execution, the representative full Windows run improved from about 1h 2m to about 53m.

What changed

1. Add reusable Windows dependency prebuild

  • add a dedicated Windows dependency build workflow
  • package and reuse the dependency payload for smoke jobs
  • separate dependency build cost from PR-time UT validation cost

2. Add path-scoped Windows C++ smoke gates

  • add a Windows C++ smoke workflow for PR / push / manual dispatch
  • detect changed paths and map them to the smallest relevant smoke targets
  • preserve smoke logs, XML outputs, and failure evidence for CI diagnosis
  • add timeout / stale-run protections for better CI reliability

3. Migrate high-value legacy UT / smoke coverage

Stable legacy tests/fff_print cases were migrated into focused smoke targets, including coverage for:

  • config
  • placeholder parser
  • gcode writer / reader
  • model assembly
  • filament mapping
  • apply / validate
  • perimeters
  • process math
  • process core
  • object layers
  • adhesion
  • fill
  • support material
  • trianglemesh geometry

Cases that are not suitable for fast PR smoke remain outside the fast gate.

4. Expose smaller test surfaces through real responsibility boundaries

Production/test surfaces in libslic3r were split only along real responsibilities and dependency boundaries so that smoke targets can be composed explicitly and maintained independently.

The intent is to preserve business behavior while making targeted PR-time validation possible.

Validation

Representative public runs:

Full smoke before

Dependency prebuild

Full smoke after

Other supporting runs

Reviewer notes

This PR is large because it combines:

  • CI workflow changes
  • smoke target composition
  • legacy coverage migration
  • responsibility-based source splitting for targeted validation

Recommended review order:

  1. workflow / trigger logic
  2. smoke scope routing
  3. migrated smoke tests
  4. production source splits and dependency boundaries

The main review question is not "were tests added", but:

  • does this restore missing PR-time validation for relevant change areas?
  • does this reduce unnecessary UT work and feedback time?
  • are the new boundaries based on real responsibilities rather than test-only structure?
@tangkelu tangkelu mentioned this pull request Jun 16, 2026
Closed
@tangkelu tangkelu marked this pull request as ready for review June 16, 2026 10:37
@BambulabRobot BambulabRobot requested a review from MackBambu June 17, 2026 03:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant

@tangkelu