We have introduced SonarQube to our project integrated with TFS Build (2017).
That is our project structure:
SonarQube should run over App, DotNetNuke and LotesKWKPortal
The problem is that Sonar is adding only KWKPortal and LotesKWKPortal, the App folder is ignored:
Is this a problem with the Build definition or with SonarQube?
It seems like Sonar is only analysing folders with .sln files. How do I tell my TFS build to consider all folders in the repository?
EDIT:
That is how our build definition look like:
You're using the SonarQube scanner for MSBuild tasks. Per the docs, you should use the SonarQube CLI task for anything not touched by MSbuild, such as JavaScript.
Related
Is there a way to SonarQube Build breaker for multiple projects in TFS. As we have more than 100 projects in TFS, now we are updating the SonarQube Build Breaker version and we do not want to go each Build Definition and want to automate it.
You can make a script using TFS REST APIs to update build process task version.
Get Build Definition
In this link you have do documentation to use the TFS rest apis.
The JSON path to find the version spec of the task is
rootObject.process.phases[0].steps[sonarqube build braker task
id].versionSpec
Is there any similar plugin like this
https://wiki.jenkins.io/display/JENKINS/Config+File+Provider+Plugin
in TFS Build & Release
I want to provide configuration.json file which is not included in git source.
Unfortunately, there is no such extension in TFS/VSTS Build & Release.
According to your tag tfs2013, seems you are working with XAML build.
Just like you need a workspace on your dev machine to develop your app, you must specify the workspace that the build agent uses to build and test your app. Then we get/pull source files from TFS server side. It's not able to achieve below similar features in TFS UI:
Adds the ability to provide configuration files (i.e., settings.xml
for maven, XML, groovy, custom files, etc.) loaded through the Jenkins
UI which will be copied to the job's workspace.
As a workaround, you could try to put configuration.json files in a ftp server instead of git source and then use a PowerShell solution to down the files in build agent workspace. If create a PowerShell to over FTP you can have it called by the build template(customize workflow).
Have a small ASP.Net Web Application that is setup to build and release via TFS 2017 (Update 2) Continuous Integration and Deployment. It all seems to work well, I check in a code change and the change appears on our test server as expected.
However, when I review the build/release logs it's deploying all the files in my web application project as if they're new files. This includes images and the like that haven't changed.
How can I, a) restrict it to only deploy changed files, or b) only deploy the necessary web application files?
Below are the Build and Release Definitions in TFS, along with the Build and Release logs.
2018-03-13T21:46:56.8010920Z ##[section]Starting: Build
2018-03-13T21:46:56.8167174Z Current agent version: '2.117.2'
2018-03-13T21:46:57.5354799Z ##[section]Starting: Initialize Job
...
TFS 2017 Build Log
2018-03-13T07:49:31.8449259Z ##[section]Starting: Release
2018-03-13T07:49:31.8605444Z Current agent version: '2.117.2'
2018-03-13T07:49:32.6262832Z ##[section]Starting: Initialize Job
...
TFS 2017 Release Log
Cheers
Phil
Using the Copy Files task, there is no default match pattern filters could only copy changed files.
For a),you could try to use a powershell script in release definition to achieve your requirement.
which deletes all files (recursive) which have timestamp that is <
(Now - x min), and all empty directories after that. On this way
Artifact directory contains of ONLY CHANGED files (entire file
structure (of changed files) is kept). Now Release will deliver only
these files to destination.
More detail info please refer this similar question: TFS 2017 - how build/deliver only changed files?
For b), you could try to use the Build and Deployment template and by default in the MSBuild Arguments the parameter is: /p:OutDir="$(build.binariesdirectory)\\"
Have a look at this question: Build and Deploy a Web Application with TFS 2017 using Web Deploy Package
Is there anyway in sonarqube where we can run analysis on the files which have been changed by commit and get the code smells before publishing the code smells to sonar dashboard. Currently we have integrated the sonarqube analysis with Jenkins as a Job to run on a daily basis.
I saw a nice answer in sonarQube site:
You can get the list of changed files from the github api and then
plug it into sonar.inclusions . Simple.
In context to jenkins,
create a sonar.properties file (using shell)
make a github api
call and fetch the list of files changed with their api.
insert
the above fetched value inside the sonar.properties file
(sonar.inclusions=) (open file in write mode)
and pass this sonar
file to the build configuration (maven, ant etc)
In this way , there would be new sonar inclusions for each PR in
jenkins.
We are using TFS to build our projects and for analysis using Sonarqube Msbuild Runner however some of our project are bound to be builded in multiple configurations (Debug|Release) and apparently sonarqube msbuild runner doesn't support multiple configuration.
In the error message (below) suggested analyzing each configuration separately but we don't know how, due the fact that we are just calling runner with begin and end in our TFS xaml build process and everything happens automatically.
Is there a way to analyze both configuration separately or analyzing just one of them?
This is the error message that we are catching in our TFS build report:
No analysable projects were found but some duplicate project IDs were
found. Possible cause: you are building multiple configurations (e.g.
DEBUG|x86 and RELEASE|x64) at the same time, which is not supported by
the SonarQube integration. Please build and analyse each configuration
individually.
Thank you in advance.
You can try to add two pairs of Sonarqube in your build definition and specify the platform and configuration for your project.
Or declare the build variables BuildPlatform and BuildConfiguration on the Variables tab and and reference it here as $(BuildConfiguration). This way you can modify the platform when you queue the build.