Skip to content

Commit 93a50e0

Browse files
gnodetclaude
andcommitted
chore(ci): rationalize CI into single workflow with unified comment
Consolidate CI test infrastructure into a single incremental-build action with a unified PR comment, replacing the previous scattered approach with separate component-test and detect-dependencies actions. Key changes: - Merge component-test and detect-dependencies actions into incremental-build, which now handles file-path analysis, POM dependency detection, and /component-test extra modules in one script - Add POM dependency analysis: when parent/pom.xml properties change, grep all module pom.xml files for references to the changed properties and include those modules in the test set - Add pr-test-commenter.yml workflow: posts CI test summary comments using workflow_run trigger so it works on fork PRs (where GITHUB_TOKEN is read-only) - Refactor pr-manual-component-test.yml: instead of running its own build, it now resolves component paths and dispatches the main "Build and test" workflow with extra_modules and skip_full_build - Add manual-it-mapping.txt: maps source modules to their associated integration test suites. When a changed module is in the exclusion list but has a mapping entry, CI advises contributors to run the integration tests manually - Add CI-ARCHITECTURE.md documenting the full CI workflow ecosystem - Fix empty associative array crash under set -u in checkManualItTests by using a counter variable instead of ${#it_sources[@]} - Fix duplicate modules in CI comment by stripping Maven [packaging] suffix before deduplication Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1 parent 0bf9acf commit 93a50e0

13 files changed

Lines changed: 958 additions & 597 deletions

File tree

.github/CI-ARCHITECTURE.md

Lines changed: 164 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,164 @@
1+
# CI Architecture
2+
3+
Overview of the GitHub Actions CI/CD ecosystem for Apache Camel.
4+
5+
## Workflow Overview
6+
7+
```
8+
PR opened/updated
9+
10+
├──► pr-id.yml ──► pr-commenter.yml (welcome message)
11+
12+
├──► pr-build-main.yml (Build and test)
13+
│ │
14+
│ ├── regen.sh (full build, no tests)
15+
│ ├── incremental-build (test affected modules)
16+
│ │ ├── File-path analysis
17+
│ │ ├── POM dependency analysis
18+
│ │ └── Extra modules (/component-test)
19+
│ │
20+
│ └──► pr-test-commenter.yml (post unified comment)
21+
22+
└──► sonar-build.yml ──► sonar-scan.yml (SonarCloud analysis)
23+
[currently disabled — INFRA-27808]
24+
25+
PR comment: /component-test kafka http
26+
27+
└──► pr-manual-component-test.yml
28+
29+
└── dispatches "Build and test" with extra_modules
30+
```
31+
32+
## Workflows
33+
34+
### `pr-build-main.yml` — Build and test
35+
36+
- **Trigger**: `pull_request` (main branch), `workflow_dispatch`
37+
- **Matrix**: JDK 17, 21, 25 (25 is experimental)
38+
- **Steps**:
39+
1. Full build via `regen.sh` (`mvn install -DskipTests -Pregen`)
40+
2. Check for uncommitted generated files
41+
3. Run incremental tests (only affected modules)
42+
4. Upload test comment as artifact
43+
- **Inputs** (workflow_dispatch): `pr_number`, `pr_ref`, `extra_modules`, `skip_full_build`
44+
45+
### `pr-test-commenter.yml` — Post CI test comment
46+
47+
- **Trigger**: `workflow_run` on "Build and test" completion
48+
- **Purpose**: Posts the unified test summary comment on the PR
49+
- **Why separate**: Uses `workflow_run` to run in base repo context, allowing comment posting on fork PRs (where `GITHUB_TOKEN` is read-only)
50+
51+
### `pr-manual-component-test.yml` — /component-test handler
52+
53+
- **Trigger**: `issue_comment` with `/component-test` prefix
54+
- **Who**: MEMBER, OWNER, or CONTRIBUTOR only
55+
- **What**: Resolves component names to module paths, dispatches the main "Build and test" workflow with `extra_modules` and `skip_full_build=true`
56+
- **Build**: Uses a quick targeted build (`-Dquickly`) of the requested modules and their dependencies instead of the full `regen.sh` build
57+
58+
### `pr-id.yml` + `pr-commenter.yml` — Welcome message
59+
60+
- **Trigger**: `pull_request` (all branches)
61+
- **Purpose**: Posts the one-time welcome message on new PRs
62+
- **Why two workflows**: `pr-id.yml` runs in PR context (uploads PR number), `pr-commenter.yml` runs via `workflow_run` with write permissions
63+
64+
### `main-build.yml` — Main branch build
65+
66+
- **Trigger**: `push` to main, camel-4.14.x, camel-4.18.x
67+
- **Steps**: Same as PR build but without comment posting
68+
69+
### `sonar-build.yml` + `sonar-scan.yml` — SonarCloud PR analysis
70+
71+
- **Status**: Temporarily disabled (INFRA-27808 — SonarCloud quality gate adjustment pending)
72+
- **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
75+
76+
### Other workflows
77+
78+
- `pr-labeler.yml` — Auto-labels PRs based on changed files
79+
- `pr-doc-validation.yml` — Validates documentation changes
80+
- `pr-cleanup-branches.yml` — Cleans up merged PR branches
81+
- `alternative-os-build-main.yml` — Tests on non-Linux OSes
82+
- `check-container-versions.yml` — Checks test container version updates
83+
- `generate-sbom-main.yml` — Generates SBOM for releases
84+
- `security-scan.yml` — Security vulnerability scanning
85+
86+
## Actions
87+
88+
### `incremental-build`
89+
90+
The core test runner. Determines which modules to test using:
91+
92+
1. **File-path analysis**: Maps changed files to Maven modules
93+
2. **POM dependency analysis**: For `parent/pom.xml` changes, detects property changes and finds modules that reference the affected properties in their `pom.xml` files (uses simple grep, not Maveniverse Toolbox — see Known Limitations below)
94+
3. **Extra modules**: Additional modules passed via `/component-test`
95+
96+
Results are merged, deduplicated, and tested. The script also:
97+
98+
- Detects tests disabled in CI (`@DisabledIfSystemProperty(named = "ci.env.name")`)
99+
- Applies an exclusion list for generated/meta modules
100+
- Checks for excluded modules with associated integration tests (via `manual-it-mapping.txt`) and advises contributors to run them manually
101+
- Generates a unified PR comment with all test information
102+
103+
### `install-mvnd`
104+
105+
Installs the Maven Daemon (mvnd) for faster builds.
106+
107+
### `install-packages`
108+
109+
Installs system packages required for the build.
110+
111+
## PR Labels
112+
113+
| Label | Effect |
114+
| --- | --- |
115+
| `skip-tests` | Skip all tests |
116+
| `test-dependents` | Force testing dependent modules even if threshold exceeded |
117+
118+
## CI Environment
119+
120+
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.
121+
122+
## Known Limitations of POM Dependency Detection
123+
124+
The property-grep approach has structural limitations that can cause missed modules:
125+
126+
1. **Managed dependencies without explicit** `<version>` — Most Camel modules inherit dependency versions via `<dependencyManagement>` in the parent POM and do not declare `<version>${property}</version>` themselves. When a managed dependency version property changes, only modules that explicitly reference the property are detected — modules relying on inheritance are missed.
127+
128+
2. **Maven plugin version changes are completely invisible** — Plugin version properties (e.g. `<maven-surefire-plugin-version>`) are both defined and consumed in `parent/pom.xml` via `<pluginManagement>`. Since the module search excludes `parent/pom.xml`, no modules are found and **no tests run at all** for plugin updates. Modules inherit plugins from the parent without any `${property}` reference in their own `pom.xml`.
129+
130+
3. **BOM imports** — When a BOM version property changes (e.g. `<spring-boot-bom-version>`), modules using artifacts from that BOM are not detected because they reference the BOM's artifacts, not the BOM property.
131+
132+
4. **Transitive dependency changes** — Modules affected only via transitive dependencies are not detected.
133+
134+
5. **Non-property version changes** — Direct edits to `<version>` values (not using `${property}` substitution) or structural changes to `<dependencyManagement>` sections are not caught.
135+
136+
These limitations mean the incremental build may under-test when parent POM properties change. A future improvement could use [Maveniverse Toolbox](https://github.com/maveniverse/toolbox) `tree-find` or [Scalpel](https://github.com/maveniverse/scalpel) to resolve the full dependency graph and detect all affected modules.
137+
138+
## Manual Integration Test Advisories
139+
140+
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.
141+
142+
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:
143+
144+
> 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:
145+
>
146+
> ```
147+
> mvn verify -f dsl/camel-jbang/camel-jbang-it -Djbang-it-test
148+
> ```
149+
150+
To add new mappings, edit `manual-it-mapping.txt` using the format:
151+
152+
```
153+
source-artifact-id:it-module-path:command
154+
```
155+
156+
## Multi-JDK Artifact Behavior
157+
158+
All non-experimental JDK matrix entries (17, 21) upload the CI comment artifact with `overwrite: true`. This ensures a comment is posted even if one JDK build fails. Since the comment content is identical across JDKs (same modules are tested regardless of JDK version), last writer wins.
159+
160+
## Comment Markers
161+
162+
PR comments use HTML markers for upsert (create-or-update) behavior:
163+
164+
- `<!-- ci-tested-modules -->` — Unified test summary comment

.github/actions/component-test/action.yaml

Lines changed: 0 additions & 121 deletions
This file was deleted.

.github/actions/component-test/component-test.sh

Lines changed: 0 additions & 71 deletions
This file was deleted.

.github/actions/detect-dependencies/action.yaml

Lines changed: 0 additions & 39 deletions
This file was deleted.

0 commit comments

Comments
 (0)