SonarQube.Scanner.MSBuild fails on successive invocations; unable to clean .sonarqube dir - sonarqube

Basically, I need to invoke msbuild three times in succession. Each of the three builds needs to be scanned. The first one is OK, but the 2nd and 3rd fail because the scanner is unable to clean the .sonarqube directory.
I get "Access to the path 'SonarQube.Common.dll' is denied.
It appears that the .dll is still in use, even though I put a 60 second delay between the builds.
Here is a snippet of the output:
C:\home\repos\SteveKTemp>SonarQube.Scanner.MSBuild.exe begin /k:com.carestream.SteveK_Backend /n:SteveK_Backend /v:1.0 /s:C:\home\repos\SteveKTemp\src\Backend_Sonar_Properties.xml
SonarQube Scanner for MSBuild 3.0.2
Loading analysis properties from C:\home\repos\SteveKTemp\src\Backend_Sonar_Properties.xml
sonar.verbose=true was specified - setting the log verbosity to 'Debug'
Pre-processing started.
Preparing working directories...
Using environment variables to determine the download directory...
Removing the existing directory: C:\home\repos\SteveKTemp\.sonarqube
Creating directory: C:\home\repos\SteveKTemp\.sonarqube
12:50:27.707 12:50:27.703 Loading analysis properties from C:\home\repos\SteveKTemp\src\Backend_Sonar_Properties.xml
12:50:27.707 12:50:27.707 sonar.verbose=true was specified - setting the log verbosity to 'Debug'
12:50:27.708 Updating build integration targets...
12:50:27.709 The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\rocbuilder\AppData\Local\Microsoft\MSBuild\15.0\Microsoft.Common.targets\ImportBefore
12:50:27.709 The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\rocbuilder\AppData\Local\Microsoft\MSBuild\14.0\Microsoft.Common.targets\ImportBefore
12:50:27.71 The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\rocbuilder\AppData\Local\Microsoft\MSBuild\12.0\Microsoft.Common.targets\ImportBefore
12:50:27.711 Installed SonarQube.Integration.targets to C:\home\repos\SteveKTemp\.sonarqube\bin\targets
12:50:27.712 Creating config and output folders...
...
C:\home\repos\SteveKTemp>SonarQube.Scanner.MSBuild.exe end
SonarQube Scanner for MSBuild 3.0.2
Default properties file was found at C:\SonarQube\Scanners\sonar-scanner-msbuild-3.0.2.656\SonarQube.Analysis.xml
Loading analysis properties from C:\SonarQube\Scanners\sonar-scanner-msbuild-3.0.2.656\SonarQube.Analysis.xml
Post-processing started.
12:52:04.002 Loading the SonarQube analysis config from C:\home\repos\SteveKTemp\.sonarqube\conf\SonarQubeAnalysisConfig.xml
12:52:04.003 Not running under TeamBuild
12:52:04.004 Analysis base directory: C:\home\repos\SteveKTemp\.sonarqube
Build directory:
Bin directory: C:\home\repos\SteveKTemp\.sonarqube\bin
Config directory: C:\home\repos\SteveKTemp\.sonarqube\conf
Output directory: C:\home\repos\SteveKTemp\.sonarqube\out
Config file: C:\home\repos\SteveKTemp\.sonarqube\conf\SonarQubeAnalysisConfig.xml
...
:: CAUSE A DELAY BETWEEN 1st and 2nd Scan
C:\home\repos\SteveKTemp>PING localhost -n61 1>NUL
C:\home\repos\SteveKTemp>SonarQube.Scanner.MSBuild.exe begin /k:com.carestream.SteveK_WebCSharp /n:SteveK_WebCSharp /v:1.0 /s:C:\home\repos\SteveKTemp\src\Web_Sonar_Properties.xml
SonarQube Scanner for MSBuild 3.0.2
Loading analysis properties from C:\home\repos\SteveKTemp\src\Web_Sonar_Properties.xml
sonar.verbose=true was specified - setting the log verbosity to 'Debug'
Pre-processing started.
Preparing working directories...
Using environment variables to determine the download directory...
Removing the existing directory: C:\home\repos\SteveKTemp\.sonarqube
Failed to create an empty directory 'C:\home\repos\SteveKTemp\.sonarqube'. Please check that there are no open or read-only files in the directory and that you have the necessary read/write permissions.
Detailed error message: Access to the path 'SonarQube.Common.dll' is denied.
Pre-processing failed. Exit code: 1
I would greatly appreciate any help in finding a way to get around this problem.
Thank you.

I see there is an additional option they recommend when running multiple builds in succession.
pass /nodereuse:false to msbuild
See troubleshooting:
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+MSBuild

Related

Error when I run this command "fx set core.qemu-x64"

ERROR at //third_party/openssh-portable/fuchsia/developer-keys/BUILD.gn:10:24: Could not read file.
manifest = read_file("//.fx-ssh-path", "list lines")
^---------------
I resolved this to "/home/shivkumar/fuchsia_os/fuchsia/.fx-ssh-path".
See //products/core.gni:102:3: which caused the file to be included.
"//third_party/openssh-portable/fuchsia/developer-keys:ssh_config",
^-----------------------------------------------------------------
ERROR: error running gn gen: exit status 1
This error means that the //.fx-ssh-path file does not exist, or is otherwise unreadable. This file is typically generated on source checkout when the integration manifest runs //tools/ssh-keys/gen-ssh-keys.sh as a jiri hook.
To correct the problem, use gen-ssh-keys.sh again to re-generate the file(s) before setting your build configuration:
$ tools/ssh-keys/gen-ssh-keys.sh
$ fx set core.qemu-x64
Note: Hooks are also run anytime you run jiri update so you could also resync the source tree to correct the issue.

"The process cannot access the file 'Default.rd.xml' because it is being used by another process." on AppVeyor CI

I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.

"No testable files found." when trying to run NUnit though final builder

I'm trying to run Nunit unit tests using finalbuilder/continua and it's simply not working and I don't know why. I just get this error:
No testable files found. Check that you have entered valid paths for
the Files field. Also ensure that the Workspace and Repository Rules
are set up correctly to copy the files to the agent.
I have the following configuration:
I'm building the dll before hand:
I can see the dll in (what I think is) the right directory:
I turned on verbose logging but it's not helpful. I just get the same information again:
Medium: 08:52:38.824 {T12} [Debug] Running action 'NUnit MES_Helpers_Test (NUnitAction)'.
Medium: 08:52:38.840 {T12} [Execute Action] Action 'NUnit MES_Helpers_Test' has failed due to an error: No testable files found. Check that you have entered valid paths for the Files field. Also ensure that the Workspace and Repository Rules are set up correctly to copy the files to the agent.
Medium: 08:52:38.840 {T12} [Debug] Running action 'Build solution (MSBuildAction)'.
what am I missing here?
There appears to be an 's' missing from your file path.
Change:
$Workspace$\Output\MES_Helpers_Test\MES_Helpers_Test.dll
to
$Workspace$\Output\MES_Helpers_Test\MES_Helpers_Tests.dll

Visual Studio Team Services - Build fails, definition wrong?

I've been working on a project for some time now and now I want to use Visual Studio Team Services for it. Locally, the building in Visual Studio doesn't give an error and the application works as intended.
I've checked in this working code to VSTS so it's in the repo and good to go.
Now I want to build it. I created a new Build definition with nothing changed. When I run the build it fails. I tried editing the build definition but with my 0 experience with this I only screw up more and create more errors.
My problem: Apparently, it wants to find C:\a\1\s But I have no idea why and how it came up with that path.
What do I have to change in the build definition? I'm new to this so I don't know what all the settings do and where the files are that it needs.
I tried adding the .sln file from the project folder to the build definition (as shown in the 2nd image) but it still want to find that weird path.
So here are the build definitions, steps that go wrong and the errors in the logs.
NuGet restore ***.sln
2016-03-07T10:28:15.8302718Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18
2016-03-07T10:28:15.9337363Z Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18\NuGetInstaller.ps1
2016-03-07T10:28:16.5636975Z ##[error]Could not find a part of the path 'C:\a\1\s'.
2016-03-07T10:28:16.5876990Z ##[error]No solution was found using search pattern 'C:\a\1\s\**\*.sln'.
Copy Files to: $(build.artifactstagingdirectory)
2016-03-07T10:28:16.6827013Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11
2016-03-07T10:28:17.1800860Z ##[debug]check path : C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:28:17.1810857Z ##[debug]set resource file to: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:28:17.1810857Z ##[debug]system.culture=en-US
2016-03-07T10:28:17.1820859Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:28:17.1820859Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:28:17.1820859Z ##[debug]Contents=**\bin\release\**
2016-03-07T10:28:17.1830859Z ##[debug]SourceFolder=C:\a\1\s
2016-03-07T10:28:17.1830859Z ##[debug]check path : C:\a\1\s
2016-03-07T10:28:17.1840858Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\lib.json
2016-03-07T10:28:17.1840858Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:28:17.1850860Z Not found SourceFolder: C:\a\1\s
2016-03-07T10:28:17.1860857Z ##[debug]task result: Failed
NuGet restore $/Test project/QRM/QRM.sln
2016-03-07T10:47:46.0629142Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18
2016-03-07T10:47:46.1969152Z Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18\NuGetInstaller.ps1
2016-03-07T10:47:46.8519190Z ##[error]Cannot find path 'C:\a\1\s\QRM\QRM.sln' because it does not exist.
2016-03-07T10:47:46.8639180Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\agent\worker\tools\NuGet.exe restore "C:\a\1\s\QRM\QRM.sln" -NonInteractive
2016-03-07T10:47:48.8829320Z MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
2016-03-07T10:47:48.8999324Z ##[error]Could not find a part of the path 'C:\a\1\s\QRM\QRM.sln'.
2016-03-07T10:47:48.9249320Z ##[error]Unexpected exit code 1 returned from tool NuGet.exe
Copy Files to: $(build.artifactstagingdirectory)
2016-03-07T10:47:49.0239330Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11
2016-03-07T10:47:49.6659427Z ##[debug]check path : C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:47:49.6779370Z Not found SourceFolder: C:\a\1\s
2016-03-07T10:47:49.6789372Z ##[debug]set resource file to: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:47:49.6799369Z ##[debug]system.culture=en-US
2016-03-07T10:47:49.6799369Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:47:49.6809368Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:47:49.6809368Z ##[debug]Contents=**\bin\release\**
2016-03-07T10:47:49.6809368Z ##[debug]SourceFolder=C:\a\1\s
2016-03-07T10:47:49.6819369Z ##[debug]check path : C:\a\1\s
2016-03-07T10:47:49.6819369Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\lib.json
2016-03-07T10:47:49.6829365Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:47:49.6829365Z ##[debug]task result: Failed
Edit
The build definition's repository tab:
The repository structure:
According to the logs you provided:
2016-03-07T15:00:44.4590685Z Done syncing repository Test project to version 3 (workspace version -1)
This issue may caused by the access permission of your build account. Please check and make sure the account that the build agent use has the permission to access to your code repository.
Same issues for your reference:
TFS 2105 build issue
TFS 2015 Build Agent failing syncing the repository
When you queued a new build, did you enter a Source Version to get? I see a Version 3 coming by in the logs, but no files are actually transferred. If you want to fetch a specific changeset, you need to enter C3 instead of 3. But I'd recommend to just leave the box empty.

Running a generic test after a successful build using vs and TFS 2010

I'm using team explorer under vs2010 to queue a build that is configured to run an automated test after the build. The automated test section is configured to use a vsmdi file that defines one testlist with one generic test that only opens calc.exe.
Looking in the log, after the successful build, mstest generates the following error log and calc is not running on the build agent:
Run MSTest for Metadata File
The MSTestActivity was invoked without a value for Platform or Flavor. The values Mixed Platforms and Debug were used.
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe /nologo /usestderr /searchpathroot:"C:\Builds\4\CITest\CI_AUT_1\Binaries" /resultsfileroot:"C:\Builds\4\CITest\CI_AUT_1\TestResults" /testmetadata:"C:\Builds\4\CITest\CI_AUT_1\Sources\AUT1.vsmdi" /testlist:"TestList1" /publish:"http://vmftrnd70.devlab.ad:8080/tfs/QTPCollection" /publishbuild:"vstfs:///Build/Build/82" /teamproject:"CITest" /platform:"Mixed Platforms" /flavor:"Debug"
Loading C:\Builds\4\CITest\CI_AUT_1\Sources\AUT1.vsmdi...
Search path(s) for tests:
C:\Builds\4\CITest\CI_AUT_1\Binaries
C:\Builds\4\CITest\CI_AUT_1\Sources
Search path(s) for default test settings:
C:\Builds\4\CITest\CI_AUT_1\Sources
Failed to load tests from 'C:\Builds\4\CITest\CI_AUT_1\Binaries\generictest1.generictest': Microsoft.VisualStudio.TestTools.TestManagement.InvalidStorageExtensionException: File extension specified '.generictest' is not a valid test extension.
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.GetTestTypeInfosForExtension(String ext)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.GetTestTypesNotManagedInStorage(String storage)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.LoadTestsFromTipsHelper(IEnumerable`1 locations, ProjectData projectData)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.LoadTests(IEnumerable`1 locations, ProjectData projectData, TestConflictHandler vetoingHandler)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.LoadTests(String location, ProjectData projectData, TestConflictHandler vetoingHandler)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.LoadTestLinkStorageHelper.LoadTests(String fullStoragePath, ProjectData projectData)
at Microsoft.VisualStudio.TestTools.TestManagement.Tmi.SimpleLoadTestLinkStorageHelper.Load(String fullStoragePath, ProjectData projectData)
Starting execution...
Test GenericTest1 cannot be found.
No tests to execute.
I've tried all possible ways to get the generic test to run after the build with no success...
Nothing about this on msdn\google,
Thank you for any clue you can think of.
You need full Visual Studio installed to recognise the filetype
I haven't used generic tests myself, but from the msdn documentation it looks like they have to be treated as test containers.
In your build definition, change the process to use a test container and use ***.generictest instead of ***test*.dll and see if that works.
As a note, if you are firing up a GUI tool like calc.exe, then your build server will need to be running interactively otherwise you'll have test failures.

Resources