|
| 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 |
0 commit comments