[
https://issues.apache.org/jira/browse/CAMEL-24587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110586#comment-18110586
]
Federico Mariani commented on CAMEL-24587:
------------------------------------------
Hi [~gnodet] please double check it
> 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
> Priority: Major
> Labels: ci, github-actions
> 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)
