You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ci: use Scalpel skip-tests mode for single-invocation CI builds
Replace the multi-step CI pipeline (regen.sh build + incremental-build.sh
module detection + separate Maven test invocation) with a single Maven
invocation using Scalpel 0.2.0's skip-tests mode.
Scalpel now builds all modules but only runs tests on affected ones,
eliminating ~500 lines of grep-based module detection and threshold logic.
The incremental-build.sh script becomes a post-build comment generator
that reads Scalpel's JSON report.
Changes:
- Update Scalpel extension3:0.1.0 to extension:0.2.0
- Add Scalpel skip-tests flags to regen.sh (CI-only, no-op on dev machines)
- Add --skip-tests and --coverage arguments to regen.sh
- Rewrite incremental-build.sh as post-build comment generator (~200 lines)
- Simplify sonar-build.yml to use regen.sh --coverage
- Move skip-tests label check from script to workflow step
- Update CI-ARCHITECTURE.md for new architecture
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
-**Trigger**: `pull_request` (main branch) → `workflow_run` on SonarBuild completion
73
-
-**Why two workflows**: `sonar-build.yml` runs in PR context (builds with JaCoCo coverage on core modules, uploads compiled classes artifact), `sonar-scan.yml` runs via `workflow_run` with secrets access to run the Sonar scanner and post results
74
-
-**Coverage scope**: Currently limited to core modules (`camel-api`, `camel-core`, etc.) and `coverage` aggregator. Component coverage planned for future integration with `incremental-build.sh`module detection
71
+
-**Why two workflows**: `sonar-build.yml` runs in PR context (builds with JaCoCo coverage via Scalpel, uploads compiled classes artifact), `sonar-scan.yml` runs via `workflow_run` with secrets access to run the Sonar scanner and post results
72
+
-**Coverage scope**: Scalpel dynamically detects affected modules and runs tests with JaCoCo coverage on them — no hardcoded module list
The core test runner. Determines which modules to test using:
88
+
Post-build test report generator. Reads Scalpel's JSON report (`target/scalpel-report.json`) and generates a PR comment showing:
91
89
92
-
1.**File-path analysis**: Maps changed files to Maven modules
93
-
2.**POM dependency analysis** (dual detection):
94
-
-**Grep-based**: For `parent/pom.xml` changes, detects property changes and finds modules that explicitly reference the affected properties via `${property}` in their `pom.xml` files
95
-
-**Scalpel-based**: Uses [Maveniverse Scalpel](https://github.com/maveniverse/scalpel) (Maven extension) for effective POM model comparison — catches managed dependencies, plugin version changes, BOM imports, and transitive dependency impacts that the grep approach misses
96
-
3.**Extra modules**: Additional modules passed via `/component-test`
97
-
98
-
Both detection methods run in parallel. Their results are merged (union), deduplicated, and tested. If Scalpel fails (build error, runtime error), the script falls back to grep-only with no regression.
3.**Downstream modules** tested as dependents (collapsible)
93
+
4.**Upstream modules** compiled but with tests skipped (collapsible)
94
+
5.**Extra modules** from `/component-test`
99
95
100
96
The script also:
101
97
102
98
- Detects tests disabled in CI (`@DisabledIfSystemProperty(named = "ci.env.name")`)
103
-
- Applies an exclusion list for generated/meta modules
104
99
- Checks for excluded modules with associated integration tests (via `manual-it-mapping.txt`) and advises contributors to run them manually
105
-
-Generates a unified PR comment with all test information
100
+
-Parses test failures from surefire/failsafe reports
106
101
107
102
### `install-mvnd`
108
103
@@ -112,57 +107,56 @@ Installs the Maven Daemon (mvnd) for faster builds.
112
107
113
108
Installs system packages required for the build.
114
109
115
-
## PR Labels
110
+
## Scalpel: Automatic Test Selection
116
111
117
-
| Label | Effect |
118
-
| --- | --- |
119
-
|`skip-tests`| Skip all tests |
120
-
|`test-dependents`| Force testing dependent modules even if threshold exceeded |
112
+
[Maveniverse Scalpel](https://github.com/maveniverse/scalpel) is a Maven core extension that detects which modules are affected by a PR's changes and controls test execution accordingly.
121
113
122
-
## CI Environment
123
-
124
-
The CI sets `-Dci.env.name=github.com` via `MVND_OPTS` (in `install-mvnd`). Tests can use `@DisabledIfSystemProperty(named = "ci.env.name")` to skip flaky tests in CI. The test comment warns about these skipped tests.
114
+
### How it works
125
115
126
-
## POM Dependency Detection: Dual Approach
116
+
Scalpel is configured in `.mvn/extensions.xml` and runs automatically during Maven builds. In CI, it operates in **skip-tests** mode: all modules are compiled, but tests are only executed on affected modules.
127
117
128
-
### Grep-based detection (legacy)
118
+
Detection capabilities:
119
+
-**Source changes**: Files changed in a module's directory
120
+
-**POM changes**: Property, dependency, and plugin changes in any `pom.xml`
121
+
-**Transitive dependencies**: Changes that propagate through the dependency graph
122
+
-**Managed dependencies**: Version changes via `<dependencyManagement>` (even without explicit `<version>` in child modules)
123
+
-**Managed plugins**: Plugin version changes via `<pluginManagement>`
The grep approach searches for `${property-name}` references in module `pom.xml` files. It has known limitations:
126
+
### Configuration
131
127
132
-
1.**Managed dependencies without explicit `<version>`** — Modules inheriting versions via `<dependencyManagement>` without declaring `<version>${property}</version>` are missed.
133
-
2.**Maven plugin version changes** — Plugin version properties consumed in `parent/pom.xml` via `<pluginManagement>` are invisible to child modules.
134
-
3.**BOM imports** — Modules using artifacts from a BOM are not linked to the BOM version property.
135
-
4.**Transitive dependency changes** — Only direct property references are detected.
136
-
5.**Non-property version changes** — Structural `<dependencyManagement>` edits without property substitution are not caught.
128
+
Scalpel flags are set in `etc/scripts/regen.sh` when running in CI (`GITHUB_ACTIONS=true`):
137
129
138
-
### Scalpel-based detection (new)
130
+
| Flag | Value | Purpose |
131
+
| --- | --- | --- |
132
+
|`scalpel.mode`|`skip-tests`| Build all, test only affected |
133
+
|`scalpel.skipTestsForUpstream`|`true`| Don't test upstream-only modules |
134
+
|`scalpel.fetchBaseBranch`|`true`| Auto-fetch base branch in shallow clones |
|`scalpel.reportFile`|`target/scalpel-report.json`| JSON report for PR comment |
137
+
|`scalpel.impactedLog`|`target/scalpel-impacted.txt`| Simple module path list |
139
138
140
-
[Maveniverse Scalpel](https://github.com/maveniverse/scalpel) is a Maven core extension that compares effective POM models between the base branch and the PR. It resolves all 5 grep limitations by:
139
+
### Developer machines
141
140
142
-
- Reading old POM files from the merge-base commit (via JGit)
143
-
- Comparing properties, managed dependencies, and managed plugins between old and new POMs
144
-
- Resolving the full transitive dependency graph to find all affected modules
145
-
- Detecting plugin version changes via `project.getBuildPlugins()` comparison
141
+
On developer machines, Scalpel is a no-op: without `GITHUB_BASE_REF` (set by GitHub Actions for PRs), no base branch is detected and Scalpel returns immediately. Zero impact on local builds.
146
142
147
-
Scalpel runs in **report mode** (`-Dscalpel.mode=report`), writing a JSON report to `target/scalpel-report.json` without modifying the Maven reactor. The report includes affected modules with reasons (`SOURCE_CHANGE`, `POM_CHANGE`, `TRANSITIVE_DEPENDENCY`, `MANAGED_PLUGIN`).
143
+
### Fail-safe
148
144
149
-
### Dual-detection strategy
145
+
If Scalpel encounters an error, `failSafe=true` (the default) causes it to fall back to a full build — all tests run. This means Scalpel errors never cause false negatives (missed tests).
150
146
151
-
Both methods run in parallel. Results are merged (union) before testing. This lets us:
147
+
## PR Labels
152
148
153
-
1.**Validate Scalpel** — Compare what each method detects across many PRs
154
-
2.**No regression** — If Scalpel fails, grep results are still used
155
-
3.**Gradual migration** — Once Scalpel is validated, grep can be removed
149
+
| Label | Effect |
150
+
| --- | --- |
151
+
|`incremental-skip-tests`| Skip all tests (pass `--skip-tests` to regen.sh) |
156
152
157
-
Scalpel is configured permanently in `.mvn/extensions.xml` (version `0.1.0`). On developer machines it is a no-op — without CI environment variables (`GITHUB_BASE_REF`), no base branch is detected and Scalpel returns immediately. The `mvn validate` with report mode adds ~60-90 seconds in CI.
153
+
## CI Environment
158
154
159
-
Note: the script overrides `fullBuildTriggers` to empty (`-Dscalpel.fullBuildTriggers=`) because Scalpel's default (`.mvn/**`) would trigger a full build whenever `.mvn/extensions.xml` itself changes (e.g., Dependabot bumping Scalpel).
155
+
The CI sets `-Dci.env.name=github.com` via `MVND_OPTS` (in `install-mvnd`). Tests can use `@DisabledIfSystemProperty(named = "ci.env.name")` to skip flaky tests in CI. The test comment warns about these skipped tests.
160
156
161
157
## Manual Integration Test Advisories
162
158
163
-
Some modules are excluded from CI's `-amd` expansion (the `EXCLUSION_LIST`) because they are generated code, meta-modules, or expensive integration test suites. When a contributor changes one of these modules, CI cannot automatically test all downstream effects.
164
-
165
-
The file `manual-it-mapping.txt` (co-located with the incremental build script) maps source modules to their associated integration test suites. When a changed module has a mapping entry, CI posts an advisory in the PR comment:
159
+
Some integration test suites are excluded from CI. When a contributor changes a module with a mapping entry in `manual-it-mapping.txt`, CI posts an advisory in the PR comment:
166
160
167
161
> You modified `dsl/camel-jbang/camel-jbang-core`. The related integration tests in `dsl/camel-jbang/camel-jbang-it` are excluded from CI. Consider running them manually:
168
162
>
@@ -184,4 +178,4 @@ All non-experimental JDK matrix entries (17, 21) upload the CI comment artifact
184
178
185
179
PR comments use HTML markers for upsert (create-or-update) behavior:
186
180
187
-
- `<!-- ci-tested-modules -->` — Unified test summary comment
181
+
- `<!-- ci-tested-modules -->` — Unified test summary comment
0 commit comments