SonarQube server version 2025.3.0.108892 is wrongly detected as "not >=7.2.0", branch cache miss

SonarQube Server / Community Build
1

Hello, we operate

  • a SonarQube server, developer Edition, version 2025.3.0.108892
  • our repo is on Azure DevOps
  • we are using v7 of SonarQubePrepare, SonarQubeAnalyze, SonarQubePublish in our YAML pipeline (dotnet analyzer)
  • we would like to analyse our PRs and branches and benefit from the cache feature
  • PR analysis always use cache when present in target branch, so that’s good
  • when it comes to branch analysis (NOT PR), we found that SonarQubePrepare always report
Incremental PR analysis: Base branch parameter was not provided.
Cache data is empty. A full analysis will be performed.

We took some time to analyze your code and found out that there seems to be an issue with this line. Indeed, when running code below, we find that our current version (taken from our server’s /api/server/version endpoint), 2025.3.0.108892, is not recognized by semver as being greater than or equal to 7.2.0.

import * as semver from "semver";

console.log(semver.satisfies('2025.3.0', '>=7.2.0')) // True
console.log(semver.satisfies('2025.3.0.108892', '>=7.2.0')) // false

We believe this is a bug (and because we have quite a huge number of lines… 2M), this quite impairs our builds duration…

2

One information was only implied: this affects all branch analyses, whether it’s the default branch or not, whether it’s a short-lived or long-lived branch.

also: perhaps you enjoy reading logs as much as we do, so here is one (partially redacted)

version-issue.log (16.0 KB)

3

Hi,

Welcome to the community and thanks for this report!

Your complaint seems to be that branch analysis doesn’t use the cache. That’s how its designed. Only PR analysis uses the cache.

 
Ann

4

Hi G Ann, thanks for jumping on this !

My assumptions are based on this page, more particularly on this paragraph:

The caching process is as follows:

  1. Before an analysis, the SonarScanner downloads from the server the corresponding cache:

    • For a branch analysis: the cache of the branch being analyzed.

    • For a pull request analysis: the cache of the target branch.

    • Or, as a fallback, the cache of the main branch.

but then perhaps I did not find another page where it says it does not apply do dotnet analyser, in which case solving the issue I’m referring to will not really help indeed…

Can you shed some light on this please?

Best,

5

Hi,

Okay, I get the ambiguity. Keep reading (emphasis mine):

I’ll raise this internally to see if we can get some clarity added to the docs.

 
Thx,
Ann

6

Absolutely. That’s exactly where the problem lies. We had 3 successive branch analyses on the same branch (and many more, in fact it’s been running nightly on our main branch) without ever having found the cache

  • first branch analysis had no cache (but still, SonarQubePrepare seems to findout that it’s on a PR, which is not the case, so it uploaded it : we have evidence of this because
    • analyses were properly pushed to the server (see below its history)
    • subsequent PRs to that branch did use the cache
  • second branch analysis did not find the cache (and still seemed to think it’s on a PR)
  • third one did not find the cache (and still seemed to think it’s on a PR)

Below is a capture of its history. Also, please note the fact that we did find an issue with semver that probably explains a lot.

image
image882×653 56.3 KB

7

Hi,

Okay, so your complaint is not that the cache is not used to speed up branch analysis, but that it’s recreated from scratch and re-uploaded with each branch analysis?

 
Thx,
Ann

8

As stated in the title of this issue, my problem (thus complain, if you want) is that

  • branch analyses are slow
  • because the cache is not used in branch analyses
  • because there is a cache miss
  • because SonarQubePrepare does not understand what situation it’s in (in particular it estimates that it is running in a PR context)
  • probably because there is an issue with this line, that wrongly concludes that 2025 < 7 (to put it bluntly)
  • because
    • either semver has a bug
    • or it is not used properly
    • or because SonarServer API returns a version having 4 numbers (2025.3.0.108892 in our case) where it should only return 3 (2025.3.0)

Not exactly sure about the resolution that should be applied to this problem.

9

I’m happy to provide a 1-line PR (changing the call to semver to include only 3 digits), I’m simply not sure what route the team would like to go, so I’m sparing us unnecessary efforts.

Maybe something like this (with a bit more precautions)

- semver.satisfies(serverVersion, ">=7.2.0");
+ semver.satisfies(serverVersion.split(".").subarray(0,3).join("."), ">=7.2.0");

Also, perhaps this is not the root cause and would not completely solve the problem

10

Hi,

I’ll flag this thread for the dev team because it does seem that you’ve found a bug. But again, the cache is not used in branch analyses by design. Again, it’s only part of the branch analysis to make sure it’s updated for use in the next PR analysis.

Fixing the semVer bug will not impact your branch analysis speed.

 
Ann

12

Thanks Ann. Indeed if you’re right, then this section of the documentation must be fixed (emphasis mine)

  1. Before an analysis, the SonarScanner downloads from the server the corresponding cache:

    • For a branch analysis: the cache of the branch being analyzed.

    • For a pull request analysis: the cache of the target branch.

    • Or, as a fallback, the cache of the main branch.

13

Hi,

Yes, I’ve already flagged this internally. And while there’s ambiguity, it’s not wrong.

“[T]he cache of the branch being analyzed” should be downloaded - so it can be updated to reflect the newest state of the branch and then re-uploaded to the server. So the only thing you’re missing out on here is the difference between updating an existing cache and re-creating it from scratch with each new analysis.

 
HTH,
Ann

1 Like