Keeping Scanner context of past scan tasks for longer than 30 days

SonarQube
,
1

Must-share information (formatted with Markdown):

  • which versions are you using
    SonarQube Community 9.9.1.69595
  • how is SonarQube deployed: zip, Docker, Helm
    Through zip in a separate server. Database is in a separate server.
  • what are you trying to achieve
    Get detailed information from previous scans.
  • what have you tried so far to achieve this
    Access to the API. But the required information seems to be limited to 30 days,

I’m using SQ server API to get some details about the scan, but it seems that it is limited to 30days.
In the Administration → Projects → Background Tasks I can check that per each one of the jobs there is “Show scanner context”, and going back in time, it only goes back for the last 30 days.

I need to increase that time.
Is it configurable somewhere?

In the Configuration → General settings → Housekeeping I did not find any direct reference to how long that is kept.

Any help will be much appreciated.
Best,
Fran

2

Hey there.

For 5.5 years it has been locked at a non-configurable 4 weeks ([SONAR-9218] - Jira).

I don’t recall any other requests around keeping more of it. I’m curious to know what you would like to keep this data around for!

3

Hi Colin,

Thanks for the quick answer.

We use ‘sonar.analysis.extraInfo’ parameter added to the scan to set some extra data, that we will be reading from API later, for example, if a project is using a certain yaml template to perform the SQ scan (we are using Azure Devops pipelines). In reality we are only looking at the last scan info in each project.

So, is there any hope, any remediation? How often is triggered the purge?

Best,
Fran

4

Hey there.

Thanks for the context.

  • sonar.analysis.extraInfo is really intended for Webhooks – although I wish there was a way this information could be stored with an analysis and programmatically retrieved outside a scanner context
  • There are some optional analysis parameters that still might be useful, like sonar.links.ci if it could be configured to your CI pipeline / a specific CI template. Especially if you’re only worried about the information coming from the most recent analysis. These links can programatically be queried per-project.
  • The purge is triggered on the startup of the SonarQube instance.
5

Thanks for the info Colin.

6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.