jamesnetherton commented on PR #8790: URL: https://github.com/apache/camel-quarkus/pull/8790#issuecomment-4788298166
> Hard to review indeed Yes, sorry for that. Our build is pretty complex already and these kind of changes inevitably end up increasing that complexity somewhat. > Here are the current understanding of a few scenarios for double checking: > > * Update quarkus version (probably near full build as scalpel would include a lot) > * An `extensions-support` modified (scalpel should include only what's needed base on dependencies) > * Changing .github files (An empty build will be triggered) > * Test groups are rebalanced (An empty build will be triggered) > * Changing an application.properties file (scalpel should include needed dependencies) 1. Update Quarkus version — Correct. Scalpel tracks BOM property changes, so a quarkus.version bump cascades through managed dependencies and flags most modules as affected. Effectively a near-full build. That's actually an enhancement I [added](https://github.com/maveniverse/scalpel/pull/36) in the latest release. Previously it had to worked around by adding the root pom.xml as a 'full build trigger', which is a bit heavyweight & bad for Dependabot PRs etc. 2. extensions-support modified — Correct. Scalpel tracks dependencies, so only test modules that depend on the changed support module would be affected. 3. Changing `.github` files — Most are listed in the workflow `paths-ignore` section and won't trigger the workflow at all. `ci-build.yaml` itself is not in paths-ignore (it can't be — it's the workflow file). Changes to it would trigger the workflow to run. Scalpel would see it as a changed file with no downstream dependents — 0 affected modules, which falls back to a full build. 4. Test groups rebalanced — changes to `test-categories.yaml` would trigger the workflow and Scalpel would see it with no dependents — full build fallback. 5. Changing `application.properties` — Correct. Scalpel maps it to the owning module and includes that module plus dependents. I probably should given a more concise summary of what's actually happening when in incremental mode... The workflow reads a report generated by Scalpel that contains the modules affected by the changes on the PR. It then uses that info to figure out which modules need to be run in each of the separate jobs. Some noteworthy details: * For the native tests, it creates its own set of categories instead of referencing `test-categories.yml` * The camel-quarkus-examples incremental build is a bit tricky because its a separate project. So we have some logic to see if any of the changed modules are part of the example project dependency tree, and if they are, the project is built and tested. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
