Federico Mariani created CAMEL-24587:
----------------------------------------
Summary: CI: PR incremental build tests the whole project when a
core module changes (Scalpel modules bypass the 50-module threshold)
Key: CAMEL-24587
URL: https://issues.apache.org/jira/browse/CAMEL-24587
Project: Camel
Issue Type: Bug
Components: ci
Reporter: Federico Mariani
Assignee: Federico Mariani
Fix For: 4.23.0
h3. Problem
Since [PR #24368|https://github.com/apache/camel/pull/24368] (commit
71be477c97f5, 2026-07-02) the PR "Build and test" workflow runs Maveniverse
Scalpel for *every* PR. The PR description and the comment in
{{.github/actions/incremental-build/incremental-build.sh}} say Scalpel runs in
"shadow mode" and "does not affect actual test execution".
It does. The script unions {{scalpel_module_ids}} into {{dep_module_ids}},
which goes straight into the {{-pl}} list handed to Maven. The 50-module
threshold ({{maxNumberOfTestableProjects}}) and the {{EXCLUSION_LIST}} only
apply to the {{-amd}} expansion of file-path modules, so they never trigger for
this path.
Result: any PR that touches a module with many dependents (anything under
{{core/}}) tests every downstream module, including {{camel-allcomponents}},
{{camel-itest}}, {{camel-jbang-it}} and the whole components tree, on both JDK
matrix entries.
h3. Evidence
[PR #26024|https://github.com/apache/camel/pull/26024] changes 3 files
({{core/camel-support}}, {{components/camel-jetty}}, docs):
* Scalpel report: 588 affected modules (3 DIRECT, 559 DOWNSTREAM tested, 26
DOWNSTREAM skipped)
* Job log prints {{Too many dependent modules (588 > 50), testing only the
affected modules}} and then runs {{mvnd install -pl <589 modules>}}
* Test phase: 47 min (JDK 17, failed on unrelated infra), reactor of 589 modules
Other recent PRs touching {{core/}} show the same pattern:
||PR||Modules tested||Test phase per JDK||
|#26022|589|1h 51m|
|#26018|~590|~2h|
|#26011|~590|~2h|
|#25731|~590|~2h|
|#26007 (no core change)|9|~25 min|
The PR comment contradicts itself: it says "Dependent modules were not tested
because the total number of affected modules exceeded the threshold (50)" and
then lists ~620 modules in the reactor section. The "Scalpel shadow comparison"
reports "current: 561 all tested" and cannot detect the discrepancy because
"current" already contains Scalpel's set.
h3. Proposed fix
Apply the dependent-module threshold to the dependency-detected set as well:
* After merging grep and Scalpel results, count the modules. If the count
exceeds {{maxNumberOfTestableProjects}} and the PR does not carry the
{{incremental-test-dependents}} label, test only the changed modules.
* Report the skipped count in the PR comment so the behaviour is visible.
* Fix the "shadow mode" wording in the script and in
{{.github/CI-ARCHITECTURE.md}}.
Refinement to consider (keeps coverage for wide dependency bumps): exempt
Scalpel's {{DIRECT}} modules from the cap and apply it only to {{DOWNSTREAM}}
ones. Recent Dependabot bumps of {{parent/pom.xml}} affect 0-36 modules and are
below the threshold either way; a Jackson or Spring bump would exceed it.
Note: the {{incremental-test-dependents}} label has been used on exactly one PR
(#22140, March 2026). The unmerged branch {{ci/scalpel-only-detection}} keeps
the same behaviour unless the threshold is applied to Scalpel output.
h3. Related
* CAMEL-24290 (CI under heavy load)
* CAMEL-23565 (skip Scalpel for root pom.xml changes)
_Drafted by Claude Code on behalf of Croway_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
