/api/issues/search: How to differentiate between no issues for a component and no component with that given key

[Michael Rüegg]

Hi,

I have a question related to the REST endpoint /api/issues/search. As it is currently implemented, I see no way to differentiate between the two scenarios where 1) there are no issues for a component or 2) if there is no component with the given key (/api/issues/search?components=unknown) because both just return an empty list. Or have I overlooked something? Is this something you would likely address?

Thinking about this, scenario 2) could have two sub-scenarios: 1) when the given key is just wrong or 2) when there are no results for the given key because the file did not get analyzed with SonarQube (e.g., a README.md file). So actually, I want to differentiate between the three :-)

I think this differentiation (either with an HTTP code like 404 or with different results) is really important for users of the REST interface because only with this differentiation we could yield sensible error messages to our users.

This got already raised here: https://jira.sonarsource.com/browse/SONAR-6006

Best regards,
Michael

[G. Ann Campbell]

Hi Michael,

You're asking too much of the humble issues service.

Instead, you should look to the api/resources services to verify resource existence first. 

Ann

[Michael Rüegg]

Hi Ann,

Thanks for your reply.

Doing a lookup on /api/resources with the SonarQube project key is unfortunately quite inefficient for large projects. And I can still not differentiate between the two cases where 1) the component does not exist because it is ignored by SonarQube (e.g., README.md) or 2) the component key being wrong. The latter can happen for 3rd party tools that need to generate a component key out of a file path by analyzing the build files which can be quite a complex task for multi-module builds (e.g., mapping componentXYZ/src/main/java/Main.java to projectXYZ:componentXYZ:feature/branchXYZ:src/main/java/Main.java).

Is there any chance to get /api/issues/search being improved for the described scenarios?

Best regards,

Michael

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/Yy6Tsbf8ulI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/ebffbbcb-4bd9-48de-b98c-6c77bddc98ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Brandhof]

Michael, your reasoning about unknown component can be applied to all other criteria of this web service : search by assignee, action plan, language, rule or tag. Would you return 404 if one of these criteria does not exist ? Moreover what would you suggest on criteria with multiple values (list of components, assignees, ...) if one of the values does not exist ?​

Thanks

[Michael Rüegg]

Hi Simon,

Thanks for your feedback. That sounds reasonable.

I just wished there would be a simple and efficient way to check if a SonarQube component ID is valid (i.e., is this key part of this SonarQube project) or not without fetching all components from a SonarQube project with /api/resources and checking them against the one of interest.

Any hints would be much appreciated.

Best regards,
Michael