From the following blog post:
Note that this mode is not intended to evaluate this software. Please
use a demo version or request a temporary license key to try out the
analyzer.
Do I understand it correctly, that I cannot add the following comment section to every source file in the open-source project in order to analyze it with PVS-Studio?
// This is an open source non-commercial project. Dear PVS-Studio, please check it.
// PVS-Studio Static Code Analyzer for C, C++, C#, and Java: http://www.viva64.com
Because otherwise it would be a fact of software evaluation and I need to download a demo version of PVS-Studio for that? Considering the fact that I'm not a maintainer of the project I'd like to analyze but only a person who would like to collect the static analysis report and send it to the project's maintainers.
Do I understand it correctly, that I cannot add the following comment
section to every source file in the open-source project in order to
analyze it with PVS-Studio?
The article mentioned that PVS-Studio team considers adding these comments for the analysis, then removing them (without committing to version control) to be inappropriate use of the free mode. As you will not be able to commit these comments, the answer to your question will be, unfortunately, no, you can not.
However, if you take active part in the development of the aforementioned project, you can try applying for the free license for open source projects: https://www.viva64.com/en/b/0600/
So, as I understand you're not a project developer, but you want to help the project by finding bugs with PVS-Studio and sending information about them to developers. Hmm. We didn't think about such a usage scenario. I think, a free PVS-Studio licensing option will be right for you. We provide it for developers of open projects. You can specify your GitHub/Bitbucket profile and get the key for one year. For more information, this and other free licensing options are covered in the article "Ways to Get a Free PVS-Studio License".
Note. I want to just warn you from the following scenario. If you just check the projects and send the analyzer's reports, it will be perceived negatively. If you really want to yield benefits to the project, describe specific errors! Or you can pre-filter the report to weed out false positives and leave only the warnings that are likely to indicate defects. Also see the note. "I've sent a PVS-Studio text log to the project authors! Did I really help?". And if you send the filtered report, it’s best to use the following format of its presentation: PVS-Studio Reports Now in Html , Managing XML Analyzer Report (see the section Converting the analysis results).
Related
we have a legacy code (10 years old), I want to bypass that code not to be analyzed in SonarQube. Or, SonarQube should scan only recent changes which i made to the legacy code or new files. How to achieve this. I found the CutOff Plugin is deprecated since SonarQube4.0 , we are using SonarQube 7.5
Please help
SonarScanner doesn't support analyzing only part of source code (example: only newer than a specified date). It always scans everything. If you keep your legacy code in other packages than the new code, then you may configure exclusion filter to just ignore the old code. You have to set the sonar.exclusions parameter (comma-separated list with ignored paths). You can read more about Narrowing the Focus in the official documentation.
Be aware that the proposed solution is not recommended. SonarScanner is able to find many vulnerabilities which should be fixed also in legacy code. It can prevent your company against material (e.g. money) and non-material (reputation) losses. The recommended way is to scan all code, and use Quality Gate to prevent introducing new issues. You can read more about it in Fixing the Water Leak.
I know that the 5.0 release note say "After the migration, source syntax-highlighting won't be available on a project until it has been successfully analyzed"
BUT, i can't imagine that there is no way to activate just by running another analysis. In fact, when you have thousands of components (it's our case), you can't plan 4500 analysis just to "restore" a basic but helpful functionality ! And it's more true when you know that the majority of theses components wasn't changed since a time ago... :(
So, please, say me that we can write a little batch or program that will do the job without need to pull all the sources ! I don't know how because i don't' understand this limitation of this upgrade (why sources aren't accessible)
You should trust the release notes. Information required for syntax highlighting is computed during analysis. Note that it also requires the language plugins to support this feature. I suggest to upgrade them to latest versions.
My team uses the Radiator View plugin for Jenkins for fast feedback on the build status of a few different projects. One thing we discussed that would be helpful is if the SVN revision number were included in this view. After only a quick Google search, I haven't found a clear answer on whether this plugin is configurable or not; does anyone know if there's a straightforward way to add this information?
I dont think there are customizable figures there but what you can do is, pull down the source and get the revsion numbers for all the failing builds, you will have to write the code yourself, but from what I can see there is no way of doing this with the configuration options.
What you might want to try if you just need to get that information is the recent changes on the build page of the recently broken build.
Goodluck.
Can I ask why it would be helpful to have the svn revision number on display? As far as I understand it, a build radiator is supposed to 'radiate' meaningful information into the room. The svn number is fairly meaningless unless you can look up the number in the repository, in which case you could have just looked up the revision number on Jenkins anyway.
I'm just guessing, and do correct me if I'm wrong, but I suspect that your real desire is to have some way of quickly working out who might be responsible for a failing build. If this is the case, then processing check-in comments and displaying pictures of the users involved is a far more effective way of getting developers to react to failing builds. I've experienced this first hand at my company.
With this in mind, I have developed a standalone build radiator webapp that talks to Jenkins over its REST API. CI-Eye is trivial to set up, and will probably give you better results in the workplace than the Radiator View plug-in. Give it a try, and let me know what you think -- I'm quite actively improving it, and welcome any feedback.
CI-Eye is free and open source -- see the CI-Eye wiki for more details.
Are there any useful plugins for source code metrics for Hudson/Jenkins?
I'm looking for total lines of code, total number of tests, classes, etc. with graphing.
Does anything like this exist?
Are you using Java? If so, SONAR should certainly be your first port of call. It does a lot on it's own and also wraps up all the major Java analysis tools, such as:
Out of the box, you'll get metrics on:
Potential Architectural & Design issues
Unit test coverage (uses cobertura)
Lines of code\packages\classes etc
Potential bugs
Code duplication
Adherence to code formatting standards
(plus many more)
It allows you to traverse from the high level analysis through to the source code it relates to. It will be easier if you're using Maven for your build though...
There is a Hudson plugin. And it's free.
Try CCCC (http://sourceforge.net/projects/cccc/). It does code counting, module counting (classes), etc., and the plugin also graphs it for you. (for C, C++)
Incidently, what language are you looking at?
There's also CLOC (Count lines of Code) which will tell you how many lines of each language you have, although I can't seem to find a link for it.
You don't specify which language you are using, but Redsolo's awesome blog post Guide to building .NET projects using Hudson shows you how to use FxCop and NUnit on Hudson to give some of what you are looking for. The Violations plugin used also supports Simian, CPD, PMD and PyLint.
I use cruisecontrol.rb for CI and FogBugz for bug tracking, but the more general the answers, the better.
First is the technical problem: is there an API for FogBugz? Are there good tutorials, or better yet, pre-written code?
Second is the procedural problem: what, exactly, should the CI put in the bug tracker when the build breaks? Perhaps:
Title: "#{last committer} broke the build!"
Body: "#{ error traces }"
I suppose this presupposes the answer to this question: should I even put CI breaks into my bug tracking?
At my company we've recently adopted the (commercial) Atlassian stack - including JIRA for issue tracking and Bamboo for builds. Much like the Microsoft world (I'm guessing - we're a Java shop), if you get all your products from a single vendor you get the bonus of tight integration.
For an example of how they've done interoperability, view their interoperability page.
Enough shilling. Generally speaking, I can summarize their general approach as:
Create issues in your bug tracker (ex: issue key of PROJ-123).
When you commit code, add "PROJ-123" to your commit comment to indicate what bug this code change fixes.
When your CI server checks out the code, scan the commit comments of the diffs. Record any strings matching the regex of your issue keys.
When the build completes, generate a report of what issue keys were found.
Specifically to your second problem:
Your CI doesn't doesn't have to put anything into your bug tracker. Bamboo doesn't put anything into JIRA. Instead, the Atlassian folks have provided a plugin to JIRA that will make a remote api call into Bamboo, asking the question "Bamboo, to what builds am I (a JIRA issue) related?". This is probably best explained with a screenshot.
All the CI setups I've worked with send an email (to a list), but if you did want—especially if your team uses FogBugz much as a todo system—you could just open a case in FogBugz 6. It has an API that lets you open cases. For that matter, you could just configure it to send the email to your FogBugz' email submission address, but the API might let you do more, like assign the case to the last committer.
Brian's answer suggests to me, if your CI finds a failure in a commit that had a case number, you might even just reopen the existing case. Like codifying a case field for every little thing, though, there's a point where the CI automation could be "too smart," get it wrong, and just be annoying. Opening a new case could be plenty.
And thanks: this makes me wonder if I should try integrating our Chimps setup with our FogBugz!
CC comes with a utility that warns you when builds fail, it probably isn't worth logging the failing build in FogBugz - you don't need to track issues that are immediately resolved (as most broken builds will be)
To go the other way round (FogBugz showing checkins that fixed the issue) you need a web based repository browser - FogBugz is easy to configure so that it shows the right changes.