Hi everyone! I've been trying to wrap my head around our new SonarQube setup (we're on the Developer edition). My team is a bit swamped, and running a full analysis on our entire codebase takes ages. It feels like overkill, especially for our quick daily merges.
I heard a rumor that you can configure SonarQube to only scan the code that was changed in, say, the last 30 days. Is that actually possible? I'm mostly looking at our GitHub Actions workflow and the SonarScanner properties.
I get the basic `sonar.projectKey` stuff, but I'm not sure what magic flag I'm missing. I see things like `sonar.inclusions` and `sonar.exclusions`, but that seems more for file patterns, not date ranges. Is there a setting for this, or do I need to somehow generate a list of changed files and feed *that* to the scanner?
Any pointers would be super helpful. I'm probably missing something obvious that all the experienced folks just know 😅
The rumor's partially true, but the implementation isn't a simple scanner flag. SonarQube itself doesn't have a native "scan last 30 days" property. What you're describing is typically achieved by integrating with your SCM to get the diff.
You need to generate the list of changed files from Git and pass it to the scanner using `sonar.inclusions`. Here's a basic skeleton for a GitHub Actions step that does this:
```yaml
- name: Get changed files
id: changed-files
uses: tj-actions/changed-files@v44
with:
since_last_remote_commit: 'true'
- name: SonarQube Scan
uses: SonarSource/sonarqube-scan-action@v4
with:
args: >
-Dsonar.inclusions=${{ steps.changed-files.outputs.all_changed_files }}
```
The catch is formatting the file list correctly (comma-delimited, relative paths) and handling cases where the list is empty. It's more of a CI pipeline integration than a SonarQube configuration.
IntegrationWizard
Exactly, the CI pipeline is the real configuration point for this. I'd add that while using `sonar.inclusions` with a generated list works, you need to consider the "ripple effect" in your analysis. A change in one file might impact the analysis of an untouched, dependent file.
This approach is great for speed, but it's a tactical optimization, not a strategic scan. You'll still want a full background scan periodically - maybe weekly - to catch those architectural issues that only appear when looking at the whole picture. Treat the daily diff-scan as a fast safety net.
Also, watch out for your formatting step. The output from that changed-files action often needs to be massaged into a comma-separated list without line breaks, and you have to set a sensible fallback for the first commit in a new branch.
null