Hey there.
Originally I thought this might be related to another issue of analysis triggering unexpectedly. I no longer think that, so you can ignore my previous post. 
A couple of things to check based on your sonar-scanner command and the issues you’re describing with coverage:
1. Let SonarQube/GitLab Handle Branch Names Automatically
You’re currently setting -Dsonar.branch.name=$CI_COMMIT_REF_NAME manually. In the context of GitLab CI, SonarQube is designed to automatically detect branch and PR information through environment variables and the integration with the GitLab pipeline. Setting this property manually can sometimes lead to unexpected results, especially with how analyses are categorized (branches vs PRs vs main).
I recommended removing the -Dsonar.branch.name=$CI_COMMIT_REF_NAME line from your scanner command and let the GitLab integration do the work. This often resolves issues like all analyses getting submitted as branch analysis instead of PR, main, etc.
2. Pipeline Job Configuration
What you’re describing (coverage flipping between 0% and correct values) is often seen when:
- Not all jobs (like tests) are being triggered for all pipelines (e.g., some PRs or branch builds may be skipping the test and coverage export step).
- Coverage reports (
coverage.xml) are not always being generated or picked up by the scanner.
Check your CI job definitions to make sure all relevant stages are being run for every relevant pipeline and that the coverage.xml file is present and up to date at the time SonarQube analysis runs. Feel free to share you full Gitlab CI YML here.!
3. Debugging Coverage Import
To dig deeper, check the SonarQube scanner logs for how it’s handling the coverage.xml file in each build. The scanner logs verbose information about what coverage files are found, imported, or missing. This can help you spot differences between runs that succeed vs those that show 0% coverage.
You can find guidance here on how find those logs:
Let us know what you find after trying these steps!