SonarQue API bug?

SonarQube Server / Community Build
,
1

We are running sonarqube 10.4, and i´d like to know if the problem describe below is a bug (and probably fixed in newest version). Here it goes:

I have what seems to be an error with using the API to fetch measures and the analysis history, for a subset of my projects. The example I have is this:
https://sonarqube.internal.is/api/measures/component?component=My.Component &metricKeys=last_commit_date
{

    "component": {
        "key": "My.Component",
        "name": "My.Component",
        "qualifier": "TRK",
        "measures": [
            {
                "metric": "last_commit_date",
                "value": "1718808384000"
            }
        ]
    }
}

Here the value for the latest commit translates to Wednesday, 19. June 2024 14:46:24, despite the latest analysis (as of 16th of January) being performed the said project on January 15, 2025 at 2:54 PM.
When the history of analysis is fetched for the SQ project is viewed:
https://sonarqube.internal.is/api/project_analyses/search?project=My.Component&category=VERSION&ps=500&p=1

       {
            "key": "64ad6d90-b508-416c-ab2c-b18af2c5de0a",
            "date": "2024-06-19T14:49:54+0000",
            "events": [
                {
                    "key": "8c423ddf-2f25-45f1-9b5b-ef0dc3055c7f",
                    "category": "VERSION",
                    "name": "1.20.9+1697"
                }
            ],
            "projectVersion": "1.20.9+1697",
            "manualNewCodePeriodBaseline": false,
            "revision": "f05c37aa31407eb6d56836d6e799b90f76ee17aa",
            "detectedCI": "Azure DevOps"
        },

We find that the analysis closes to this date and time is the one above. The revision hash (f05c37aa31407eb6d56836d6e799b90f76ee17aa) turns out to be consistent with the underlying repository and the exact time reflected in the epoch value before.
Image
However, this is a commit and build associated with the 1.20 version of the code, while the current version is 1.29 and the version progression has been consent throughout. So no immediate explanation for the this date popping up is apparent from this evidence. Especially, when the search_history at the time of the analysis is used:
https://sonarqube.internal.is/api/measures/search_history?component=My.Component&metrics=security_hotspots,security_rating,last_commit_date &from=2025-01-15T14:54:02%2B0000&to=2025-01-15T14:54:02%2B0000
And we find that the analysis information and dates are correct for all values at this moment in time, except the last_commit_date:

{
    "paging": {
        "pageIndex": 1,
        "pageSize": 100,
        "total": 1
    },
    "measures": [
        {
            "metric": "security_rating",
            "history": [
                {
                    "date": "2025-01-15T14:54:02+0000",
                    "value": "1.0"
                }
            ]
        },
        {
            "metric": "last_commit_date",
            "history": [
                {
                    "date": "2025-01-15T14:54:02+0000",
                    "value": "1718808384000"
                }
            ]
        },
        {
            "metric": "security_hotspots",
            "history": [
                {
                    "date": "2025-01-15T14:54:02+0000",
                    "value": "0"
                }
            ]
        },
    ]
}

The same behaviour applies to only a handful of our projects, out of some hundreds. They are still enough in number to cause some difficulty with automating parts of the release pipeline. Therefore, it would be good to know if this is a bug and if there is a workaround.

2

Hey @Andres_Co

I admit that I had no idea this metric existed. It’s documented nowhere, nor is it used in the UI.

The only reference I can find to it is the ticket in which it was created: SONAR-6824, where we also stated:

We should make this metric “hidden” for the moment, there are too many places in SQ where it won’t be handled correctly.

If we had come across this metric on our own, we would probably deprecate it. How did you come across it?

That said, on spot checks of our internal instance of SonarQube, I haven’t encountered any inconsistent spots.

How are you using it to automate your release pipeline? Maybe there’s a better option.

3

Thanks for your answer Colin,
We came across this metric in the usual way, querying /api/metrics/search, where both hidden and public metrics are listed. Though there is an expectation that ‘hidden’ metrics might be removed, this one is unique in our experience in returning inconsistent values.
The use case that was being solved is determining if the latest available analysis on the default branch in SQ was run on old code, which we see as an indicator that the feature branch/branches have not yet been merged into the main/master so the overall grade does not actually reflect the status of the next release that is being evaluated.

4

Hey @Andres_Co

With some further testing, I can indeed make last_commit_date act strangely. For example if I delete a file from the repo (or just delete some lines of code) and commit, the last_commit_date for the project does not update.

That’s enough to say that there’s something wrong here and we should either investigate or properly get rid of this metric.

It seems to me like using the SCM revision would be a better indicator of whether or not the latest analysis matches what commit you want to deploy (the revision from GET api/project_analyses/search)

10

I gave a quick look at the code, and the metric is computed for each file (that’s because we only collect SCM data per file, while doing the blame).

Then I think there is an attempt to aggregate the measure at the project-level. This is a bit tricky, because we don’t collect the last commit date for the overall project on scanner side.
So the strategy seems to have been to consider that the more recent commit date for all project files analyzed by SonarQube is going to be the project last_commit_date. Again, this might be wrong, we could have a more recent commit at the project-level, not touching any file SonarQube analyzes. This is for example your case with the deleted file @Colin.

Those limitations are expected according to the ticket SONAR-6824.

Now looking at the code, I think that in addition to the mentioned limitations, there is also a bug. It seems each file processed is also setting the date measure on the project. It means the last file processed is going to “win”, and have its last commit date set at project level. There is of course no guarantee that the last processed file is the one being modified the more recently.

I will try to confirm the issue, and create a ticket if needed.

12

OK, my bad, there is in fact some code taking the max date of all children files before setting the date on the parent.

So @Andres_Co I suggest you look at the value of the last_commit_date measure on each file in your project. The value on the project should be equal to the max.

I did a quick test, and everything is working fine on my side.