Branch: refs/heads/sonar-pr-analysis Home: https://github.com/xwiki/xwiki-platform Commit: 473ea5c5f537ed0118a05e2938c9307e7b15bea1 https://github.com/xwiki/xwiki-platform/commit/473ea5c5f537ed0118a05e2938c93... Author: Vincent Massol <[email protected]> Date: 2026-08-27 (Thu, 27 Aug 2026) Changed paths: A .github/workflows/sonar-pr.yml Log Message: ----------- [Misc] Analyze pull requests with SonarCloud and fail on their quality gate * Add the SonarCloud pull request analysis xwiki-commons and xwiki-rendering already run, so that a change introducing SonarQube issues is caught before it is merged instead of turning the master quality gate red afterwards. * Build and scan only the modules owning the files the pull request changes, passing them to the build and to sonar:sonar with -pl. A pull request analysis reports on its own new code only and every condition of the XWiki quality gate is on a new code metric, so an untouched module can neither contribute an issue nor fail the gate. Building the 532 modules of the reactor to analyze the few a pull request touches would make the job too slow to gate a merge on. * Select every ancestor aggregator of a changed module along with it, and always select the root: sonar:sonar rebuilds the project tree out of the reactor and fails on an orphan module or on a reactor with no top level project. * Ignore a changed file whose module is not in the reactor this workflow builds, a functional test module or a distribution module: -pl rejects such a path, and a whole reactor build does not analyze those either. * Fall back to the whole reactor when the root pom or an aggregator pom changed. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications