I use Gerrit-Sonar plugin in my Jenkins jobs.
When I run the job, I get an exact result in the logs, that "n issues were found" and the report was sent to Gerrit. However, when I watch the review in Gerrit, it says that "No issues were found" and review gets a +1 score.
What could be the cause of this behaviour?
I assume this issue is related to your filter settings.
So, what are the possible reasons of so many issues being ignored?
First, sonar report contains all issues of the project.
If you have your flag "Report new issues only", then all the issues that are already exist in sonar database will be omitted.
Next, flag "Add comments to changed lines only" allows plugin to ignore all issues that belongs to lines of code not changed in current commit. (For example, if sonar database refreshes once a day, all issues created in all commits during that day will be new, but only author of each of them supposed to care - so they are only visible to the author.
Finally, by default only issues with Major (and higher) severity will mark build as failed.
You may change filter settings. See project Wiki for details on how to do that.
This behaviour could also be related to the issue JENKINS-43047 with nested modules. If your project has several nested levels, the path of module component in the exported sonar-report.json is not the full path but the path component of the module. The plugin hasn't process it correctly before the version 1.0.8.
Another issue is JENKINS-43730, if you have 0 project configurations added. Add default configuration so your sonar report could be found by plugin
Related
I am not using ANT at all so the proposed duplicate does answer this question about Jenkins.
I am working on a build script that will increment the version number of the program. To do this the version file will be checked out, next version number computed and written back, and then checked in.
It occurs to me that this will trigger yet another build in an endless cycle. When we used TFS builds we could put a string in the check in comment like ***NOCI*** or something and that check in would be ignored and not trigger a new build.
Is there any such option for Jenkins or a technique I can apply myself to solve this?
I am using the TFS plugin to access my SCM.
The Subversion SCM plugin allows you to specify paths that will be excluded when polling for new versions. Git SCM also can be configured to exclude some regions.
By excludng the file that contains the version number you will be able to avoid the vicious circle that you observed.
Since you cannot cloak or .tfignore your versioning file...you can use the NOCIOption property, and pass in the flag for it, in your comments.
You would setup the NOCIOption property of the SyncWorkspace workflow activity in TFS, and during your version change, pass "****NO_CI***" flag in the comments of the checkin. This is kind of hackish and could be avoided if you used GlobalAssemblyInfo.cs versioning, linked throughout your project instead.
I suggest not using your "versioning" file, as it's fundamentally wrong for the reason of cyclic checkins. I would suggest using the GlobalAssemblyInfo.cs linked throughout your .NET solution and stamping that prior to calling MSBuild. It works like a champ for setting and linking versioning throughout your .NET projects in your solution. You implement Global Assembly Info in your solution as described in this answer here.
You can understand more of it here, at "What are the best practices for using assembly attributes". You could simply stamp this file (via Powershell or whatever) and call MSBuild and your version will be present in all .DLLs.
I have a TeamCity server building our deployments which is linked in with our issue trackers (both JIRA and TeamCity). If I put the right tag on the check-in comment this automatically links the build to an issue in the tracker and I can see a list of issues resolved in this build.
I'd like to aggregate this list of Issues across multiple builds. Basically, I'd like to automatically generate documentation for releases, which might comprise multiple builds. Is there any way to do this?
Issue tracker in teamcity only shows you the relevant tickets in a build. If you know the build number from where to start you can filter the list starting from that build to get an aggregate list.
Alternatively you can use a third-party tool that does something similar. Not sure what version control system you are using but we are using GitReleaseNotes to extract tickets from commits and link to Jira.
I have created some custom CodeActivity-derived clases which:
successfully check an assembly info file, GlobalAssemblyInfo.cs,
changes the value of AssemblyFileVersion,
and then checks it back in, returning the change set value.
I based some of this work on Ewald Hofman's wonderful blog Customize Team Build 2010 – Part 5: Increase AssemblyVersion
The Problem:
Later in the build, one of my projects in this solution uses the version number to create a subdirectory by getting the version number from the newly built assembly. The problem is the subdirectory always lags behind in the version number. I've noticed that when I test the build definition based on the BuildProcessTemplate, that my included change sets never include the GlobalAssemblyInfo from that build.
The build log tells me that steps 1, 2, and 3 all work. It also tells me that Associated Change Sets in the summary don't include the change set number in step 3. Does anyone know how I can work around this problem?
I found the answer to this question experimentally. As soon as a build is started, that point in the version tree is used for the associated change sets. Since I am checking out and checking in a file after that point, it is not part of the build. I got around this problem by calling my GetLatest activity after the Get All (specific), as seen in the DefaultTemplate. It's accomplishes the goal of getting my changed version number used in the assemblies.
I would like to get the issue list from Bugzilla and JIRA for an open-source project. For each issue, I'd like to collect the corresponding compilation units(for java projects, class/or interfaces files), which may relate to the issue.
Any idea on implementing this feature would be appreciated.
Many thanks!
For JIRA, there are some solutions out there you could use out of the box. See the documentation to integrate with source control for JIRA how to do it. This only works for some source control systems, you should which ones are supported. This gives you a list of change sets (e.g. for Subversion) for each issue.
Another approach could be to do it on your own through an interface to the source control system yourself. The following prerequisits have to be in place:
Your developers have the tools to add the information which issue was worked on by which commit on a per commit base.
You have rules that changes to the sources should all the time being done only for one issue at one time.
You are able to parse the additional information you will get from your version control system e.g. by a script or a program.
For Subversion and JIRA, it could work like that:
Ensure that all commits are only done if the Subversion commit message contains at least one JIRA ticket number. You may even ensure that by a pre-commit hook
Learn how to get the following information from the subversion log
The ticket IDs (by parsing the message) for each change set
The files that had changes for each change set
Collect for each file all tickets.
Show them in a format you like.
I think that this is not too useful, because ticket per class is too fine grained. Perhaps you should have a mapping of the files to modules, sub-projects, ... and collect tickets for them.
All solutions will be different depending on your selection of tools. JIRA and Subversion are here just examples :-)
The best way is to first integrate your issue tracking system with your source control. That means that whenever a developer commits a new change, it determines the set of issues related to this change. This linkage is managed by your issue tracking system and it can show you all the source files, resource files, config files that have changed in the context of an issue.
This info, will be available through the api of that issue tracking system as well.
I've seen the question related to the error message you get from TFS when a workspace is already mapped. The accepted answer for removing the workspace is alright as a workaround, but it's already getting tedious to run a delete command each time this error occurs.
What do I need to change in order to get out of having to use this workaround? I've got two builds (continuous integration and nightly deploy), and need to add at least one more build type. I followed this URL to see if there was a possible resolution there, but I'm not sure I understand it completely.
I am not sure how this is accomplished in TFS 2010, as I have not gotten to work with Team Build in 2010, yet. In 2008, though, if you expand the Builds node in the Team Project and right-right click on either of the builds, you will see a "Manage Build Agents..." option. Click into that, and it will bring up a dialog. One of the things on that dialog is an option called "Working Directory". Do you have the same hard-coded path in both of them?
By default, when you create a new build definition, it provides a calculated folder for this value. This is where the build agent will do the checkout from TFS for the build attempt. The default value is, $(Temp)\$(BuildDefinitionPath), I believe (I am not connected to TFS at the moment).
The article you link to is basically saying that you should include either that $(BuildDefinitionPath) value or the $(BuildDefinitionID) value as part of that path in that dialog so that the two builds do not try to use the same workspace. Changing the working folder to include one of those values should resolve your issue, going forward.