Native "release" reports

Suggest new features
1

Hi,
in my project we conceptually have only one long-lived branch : main
Every month we tag a commit at the tip of main (or very close to the tip of main). We would like to be able to have permanent (or semi permanent) storage of the indicators of the state of the project at this tag.
Currently, this would mean defining these tags as “long-lived branches”, even though we will only ever perform one analysis on them. Having this many long lived branch (hundreds) would also clutter the “branches” pages making real long-lived branches less visible.

Would it make sense to add a new category of analysis where you only have a single analysis (no history) that can be used to associate to each release a snapshot of the indicators ?
Or are there alternative techniques to achieve similar results ?

An even more ambitious goal would be to be able to see directly on the graph of the long lived branch the results of all these release analyses as special point that can be highlighted separatly than the analyses done at each commit. Are there plans for this ?

Thanks in advance.
Jon

1 Like
2

Just stumbled by chance on the activity tab of the new beta UI (much more visible than before in the “More>” submenu of the “main branch”, great !)

sonarcloudactivity
sonarcloudactivity1817×947 113 KB

are there guides/plans on how to do this to export indicators at these versions ? Maybe technical descriptions on what is tied to the projectversion only during the analysis, what is tied to the scm tag/branch ?

Activity and history | SonarQube Cloud | Sonar Documentation has limited information

It seems to be powered by the following APIS:
/api/project_analyses/search?id=projectkey

  "analyses": [
    {
      "events": [
        {
          "category": "VERSION",
          "name": "2.31.0-SNAPSHOT"
        }
      ],
      "projectVersion": "2.31.0-SNAPSHOT",
    },
    {
      "events": [
        {
          "category": "VERSION",
          "name": "2.30.0"
        }
      ],
      "projectVersion": "2.30.0",
      "manualNewCodePeriodBaseline": false,
    },

/api/measures/search_history?component=projectkey&metrics=XYZ

  "measures": [
    {
      "metric": "violations",
      "history": [
        {
          "date": "2023-06-14T06:40:23+0000",
          "value": "12"
        },
        {
          "date": "2024-02-21T16:29:30+0000",
          "value": "29"
        },

I couldn’t find references to these in Web API | SonarQube Cloud | Sonar Documentation and https://api-docs.sonarsource.com/sonarqube-cloud/default/landing but maybe I missed them ?

Thanks in advance !
Jon

4

Ok found the API v1 docs:

image
image1097×1049 110 KB

Not sure about v2, transitionning to portfolios ?

Anyway, maybe all that’s needed is guidance on how to use and implement releases/versions with snapshotted reports ? To avoid people mistakenly creating one long lived branch per version ?

Is all this in a transition state with the move of sonarqube to sonarcloud and that’s why I was a bit confused maybe ? In which case when the dust settles it should improve ?

I’m eager to know the official status if someone has time to answer.

Thanks in advance,

5

Hi,

Do you ever issue patches for these versions? Because if you do, then a long-lived branch is exactly what you need, so that you can check the quality of the patches before they go out.

And if this truly is a one-and-done situation, then probably what you want to do is download the regulatory report at release and store it somewhere as your long-term reflection of the quality.

Alternately, you can make sure each month’s version has an Event, which will shield it from housekeeping, so that most of the measure values stick around. You’ll then be able to see them in the activity graphs and/or query them as historical measures. The caveat here is that “new” measures aren’t kept; they’re only available on the latest analysis (because after that, they aren’t “new” anymore.)

 
HTH,
Ann

6

Hi,
thanks a lot for your time and your answer. We do occasionally issue patch releases, and we would like to track quality for these as well. However they are rare, and not maintained any longer than necessary, so I was fine with a system where this kind of versions is tracked manually. Also we don’t really want to track this kind of patch version any differently than release versions, we don’t need to compare to its base version.

Thanks a lot for all the pointers, I will look into them !