Issue List from New Code?

[un0tec]

Hi all,

Is it possible to obtain the list of issues from the last analysis performed? Reviewing the generated documentation I can see the list of issues that corresponds to the the Overall Code section, but I do not see the same for the New Code section.

SonarQube - CE - Version 8.9.1

Regards.

[Sancretor]

Hi @un0tec

Thanks for the feedback ! Unfortunately, I don't think we provide any data regarding the "New Code" section.

The main reason could be that we intended this tool to reflect the current state of the project quality, and depending on how you manage the "New Code" configuration on your project, the corresponding data might not be useful. For instance, if you do not provide any "version" during analysis... By the way, I don't know if it's easy to get the "New Code" data through SQ API... we'll have to investigate that.

So, what you would like is a way to generate the report only for the last analysis ? Or kind of a diff between the last and the previous version ? Or else, that we separate the report in two parts, one for the Overall Code section and another for the "New Code" one ?

[un0tec]

Hi @Sancretor

Thank you very much for your interest.

First of all, the tool is a great alternative to paid plugins that make reports of the current status of the project, the reports you get are very complete and are very well designed. So thank you very much for contributing this plugin to the community.

In my case, each analysis of the project is performed with a version, and I would like to send by mail a report that includes only the issues produced each time an analysis is performed (this is where the New Code comes into play). I would like to achieve this because SonarQube does not store a history of the New Code, and only lets you see the detail of the last analysis. I would need some way to have this history of issues and I thought that with this tool it would be possible.

Having said that and answering your question, I think that what I am looking for would be your first option.

I have always been surprised that SonarQube does not allow to store a history of what happened in each analysis, but the reason I have seen that they give in their official forums, is that it is because of how this would enlarge the database.

I don't know the api of SonarQube, but if at some point I can investigate how to get something like this I will not hesitate to try to contribute to this project. If on the other hand, if you consider that it is an idea that can be useful and you manage to obtain some result, Thank you so so much in advance.

Regards.

[un0tec]

Hi again @Sancretor,

I have been doing some research and have read that SonarQube's own interface uses its Web API to feed its data. If this is indeed the case, then the option we are discussing should be possible.

This stackoverflow post seems to be related.

I suppose that through the web API the date of the last analysis can be obtained and the user would not even have to report it.

Is it ok with you if we change this issue to enhancement?

Regards.

[un0tec]

Hi again @Sancretor

I have been able to check the SonarQube Web API and I have found the endpoint needed to have the source of issues since the last analysis (i.e. New Code).

• ${sonarqube.host}/api/issues/search?componentKeys=${project_key}&resolved=false&sinceLeakPeriod=true

The key is in the parameter sinceLeakPeriod=true.

As far as I have been able to check, without this parameter you get the Overall Code, I imagine that this is what the plugin uses right now to get all the issues, but I have not been able to check it yet.

All this applies to the issues, on the other hand there are the endpoints for security hotspot, measures, etc. But it is also possible.

At this point, do you think it would be easy to adapt the current behavior of the plugin so that in addition to the reports it generates right now, it generates the same reports using as data source the enpoints with the sinceLeakPeriod parameter?

To recall the usefulness of this idea, this would allow to store a history of what happened in detail in each analysis, functionality that SonarQube does not provide in order not to increase considerably the size of the database.

Regards.

[Sancretor]

Hi @un0tec

Sorry, I've been away for a while. Thanks for the support, it's highly appreciated ! Also thanks for the time you spent on documenting your idea and how to implement it ! Contributions like yours are what make this tool useful for everyone. :)

Right now it seems nice and "fairly easy" to implement IF all this could be done with the sinceLeakPeriod parameter. We'll have to make sure it truly works for all the APIs calls we do though, and adapt the report to show for which"leak period" it was generated. Ok to turn this into an enhancement, this looks like a nice addition to me ! But I still need to gather feedback from my teammates, in order to make sure we all agree on that. It may take a few days, so expect another delay...

We'll then continue to talk about how to truely implement it. :) Thanks again !

[un0tec]

Hi @Sancretor,

Thanks! I don't have much time right now, but as soon as I can I will try to do more research.

The last I could get to check was that the project use the 'requests.properties' file to store the API invocations. I will try to check which APIs would need to be duplicated and modified for this possible new functionality.

Thanks!!

[Sancretor]

Hi @Sancretor Teammates are totally OK with your enhancement proposal, they agree it's a feature we miss ! So, I can't make any promise regarding the timeline but I'll have a look into it for sure. Thanks a lot again !

The requests.properties file is used by the standalone mode only. The plugin mode directly calls SonarQube classes, but it should be quite simple to do the same.

[Sancretor]

Hi @un0tec I've been looking at how to implement this feature and... it's not as easy as we thought ! Some APIs we use do have the sinceLeakPeriod parameter, so it's easy for them. But some others don't... For instance, the measures API does not seem to use this parameter.

This needs more investigation on how to do it... I guess we also need to determine which parts of the reports will depend on the leak period (e.g. issues) and which won't (e.g. Quality Gate Status).

[un0tec]

Hi @Sancretor,

I completely agree with what you comment, a few days ago I was reviewing and came to the same conclusion.

"I guess we also need to determine which parts of the reports will depend on the leak period", this is the key. According to what I have been able to review, there are few apis that allow this parameter, which is not really a problem, it is simply not possible to provide this functionality since even the Sonar interface does not offer it.

For the moment, and to solve this particular issue, I think it would be a great step to add in the report the list of errors since the leak period. If we achieve this, we give the user the great advantage of being able to use these reports to have a history of issues between analyses, which is what we have been discussing in this issue and that Sonar does not allow to do.

Adding the issues to the current report I think it is quite simple, it is possible that this weekend I can devote time to it, if possible, I will try to implement it completely and I will tell you my progress, I will even consider the idea of making a pull request.

Thanks to you and the team for your interest!