Hey guys,
are there any plans to provide more types for Manual Metrics? Our sonar users requested: -Link (in our case a report stored on another system) -Date -Enum (predefined selection of options to choose) Any thoughts on that? Regards
Best regards,
Johannes Zink Software Developer 1&1 |
No thoughts so far??
Best regards,
Johannes Zink Software Developer 1&1 |
In reply to this post by Johannes Zink
Hi Johannes, There's no plan for such feature. Actually, we don't have much feedback about manual measures, which tends to tell that this feature is not that useful. Maybe you can share your use cases with us? Best regards,
On Tue, Apr 28, 2015 at 11:06 AM, Johannes Zink <[hidden email]> wrote: Hey guys, |
This post was updated on .
Hi Fabrice
Thanks for the response. Let's see if I can explain the use case properly :) Our IT security department tests our projects for security flaws and creates security-reports. Every project is analysed with SonarQube so they want to save the link to the related security report in SonarQube as well. Additional information like "Pentest date", "Pentest findings", etc. should also be saved. We created some Manual Metrics for them to save the information. The suggested types (link, date, enum) currently are of type "Text". Enum-type would be some kind of preselection to choose from, e.g. low, med, high. (Sounds pretty tricky to me...) New types would be "nice to have". This is where my question kicks in :) Regards, Johannes
Best regards,
Johannes Zink Software Developer 1&1 |
Thanks Johannes for sharing this with us.
I understand your use case, but I don't think that manual metrics are the good way to handle it. The information you want to store can't be considered as a "metric":
More generally, everything in SonarQube is designed around the source code itself, so every information that one wants to store in SQ should be linked to some source/test file. The black box approach of security tests makes this impossible, so such reports are difficult to integrate in SQ. And "manual measures" should not be used for that. Best regards,
On Mon, May 4, 2015 at 3:08 PM, Johannes Zink <[hidden email]> wrote: Hi Fabrice |
Hello,
On Tue, May 5, 2015 at 4:50 PM, Fabrice Bellingard <[hidden email]> wrote: > > Thanks Johannes for sharing this with us. > > I understand your use case, but I don't think that manual metrics are the good way to handle it. The information you want to store can't be considered as a "metric": > > you can't make a measure filter based on a URL for instance > such info (a vulnerability report) should be linked to a specific snapshot whereas manual measures are just "blindly" propagated from one snapshot to the next one > > , so in fact using the "manual metric" feature to achieve what you want would be a hack. > > More generally, everything in SonarQube is designed around the source code itself, so every information that one wants to store in SQ should be linked to some source/test file. The black box approach of security tests makes this impossible, so such reports are difficult to integrate in SQ. And "manual measures" should not be used for that. > But then, when exploring the source a little, I see that a MetricDef has methods {get,set}Data(); is this something which is to be removed or is this for something else entirely? -- Francis Galiegue, [hidden email], https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/fge/grappa --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
This post was updated on .
In reply to this post by Fabrice Bellingard-4
You got a point there and I agree with you! The information can't be considered as a "Metric" and it's not a good way to handle the use-case, but sadly it's currently the only way. :(
Some users can be very persistent to get what they want (even by misusing other features)... Especially the ones with power. Okay, no new types for Manual Metrics. :) Some quick thoughts: What do you think about a feature to add notes/information to a project? Again, it's information that is not directly linked to source/test file. But, I can image that there are some use-cases for this (besides mine). E.g. if I want to store the name of the product owner on a project. :)
Best regards,
Johannes Zink Software Developer 1&1 |
In reply to this post by fge
This won't be removed. This is used internally to store information that is more complex than just an integer or a boolean - like the complexity distribution for instance. Such metrics can't be used in measure filters but still they are always specific to the snapshot they are attached to. Best regards,
On Tue, May 5, 2015 at 6:21 PM, Francis Galiegue <[hidden email]> wrote: Hello, |
In reply to this post by Johannes Zink
On Wed, May 6, 2015 at 11:23 AM, Johannes Zink <[hidden email]> wrote: You got a point there and I agree with you! The information can't be You might know (or not!) that you can add some links to "document" your project. Some links are populated with information from your Maven POM or sonar-project.properties file, and some are free to be set by project admins: ![]() Those links are displayed in the "Description" widget. From my point of view, this is the place where you can link your project to the central place where all the information related to your project is gathered. In most IT department, there's such a central place in order to prevent info duplication and therefore save time & energy when you have to update this info. Fabrice Bellingard-4 wrote |
Yes, I found this earlier today :)
Thank you.
Best regards,
Johannes Zink Software Developer 1&1 |
In reply to this post by Fabrice Bellingard-4
Hi Fabrice,
By the way it would be great if it was possible to create/read/update/delete these links via the webservice API. Indeed with lots of projects and multiple links it's a real pain to maintain these links and there is no way to read them. Would it be possible to create a ticket in order to add such a feature ? Thanks in advance, Michel |
Hi Michel,
Best regards,
On Wed, May 6, 2015 at 5:40 PM, Michel Pawlak <[hidden email]> wrote: Hi Fabrice, |
Free forum by Nabble | Edit this page |