Using SonarQube Developer version 8.4 with Azure DevOps 2019 (Win10 server)
Using build-wrapper-x86-64 (v6.11)
SonarScanner reports as 4.22.0
Target for analysis is a TI C2000-series Eclipse project
Analysis options in the ‘Prepare Analysis on SonarQube’ task are set up as such:
With no default SonarQube properties set anywhere else.
When the ‘Run Code Analysis’ task in my Azure DevOps build pipeline runs after successfully running the build-wrapper step, I’m getting the following error:
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 50.649s
INFO: Final Memory: 112M/651M
INFO: ------------------------------------------------------------------------
##[error]ERROR: Error during SonarScanner execution
##[error]java.lang.IllegalStateException: java.nio.file.NoSuchFileException: C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp\probe894265737726557496.pp
##[error]at com.sonar.cpp.fs.FileSystemAccess.toByteArray(FileSystemAccess.java:227)
##[error]at com.sonar.cpp.fs.FileSystemAccess.toString(FileSystemAccess.java:200)
The temp file changes each time I run, but it’s always in the same location. I suspect that this is a permissions issue where that location cannot be written to by the applications; is there an option to set where the build uses temp/scratchpad area? Other projects that also use the build wrapper are building and scanning just fine (on a different build server, though, with possibly a more loose permissions set).
@mpaladin My only issue with this is that 8.4 works just fine with another build server, and both build servers share the common (v8.4) SonarQube server. Both build servers use the same version of the build-wrapper-x86-64 and the same version of sonar-scanner. There are no configuration differences that I can find between the two build pipelines, as I’m supplying the same parameters to both.
For what it’s worth, an upgrade to 8.9 LTS is in the queue for our IT team to upgrade, but there are some bigger fish in front of it right now, so that’s why I’m trying to figure out the difference since it works on one and not the other. I’m skeptical that upgrading to 8.9 is going to suddenly fix this issue.
the version you are using is not supported anymore, which makes it difficult to help you.
It would anyway be helpful if you could share the entire analysis log, possibly the debug one, you can add sonar.verbose=true property to your analysis.
@mpaladin I’ve been told that our update to 8.9 LTS is targeted for this weekend, so assuming it all goes well, I expect that to be ready to go Monday.
At this point, after discussing with our internal SME for build server configurations with Azure DevOps, I’m almost certain that this is coming down to a build server configuration issue, coupled with a lack of being able to configure SonarQube directories for where temp/probe files are located. I am walking through configurations later today with that SME and experimenting with how the builds are done in order to check this out. I will follow up based on what I find from that walk through, and also look at adding the sonar.verbose=true to the build.
So, I think this tidbit may actually be part of what’s going on based on adding the sonar.verbose=true to the build parameters, and maybe this is something that was fixed between 8.4 and 8.9 LTS?
10:35:09.330 DEBUG: Probing compiler: [C:\ti\ccs901\ccs\tools\compiler\ti-cgt-c2000_18.12.1.LTS\bin\cl2000.exe, --cpp_default, --float_support=fpu32, -Ooff, --abi=coffabi, -o=project.out, --preproc_macros, C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp\probe3535171107382725548.tmp]
10:35:09.409 DEBUG: stdout:
10:35:09.409 DEBUG: stderr:
error: bad argument to option -O: should be one of {off,0,1,2,3,4}
10:35:09.424 DEBUG: eslint-bridge server will shutdown
10:35:10.221 INFO: ------------------------------------------------------------------------
10:35:10.221 INFO: EXECUTION FAILURE
10:35:10.221 INFO: ------------------------------------------------------------------------
10:35:10.221 INFO: Total time: 50.585s
10:35:10.815 INFO: Final Memory: 109M/640M
10:35:10.815 INFO: ------------------------------------------------------------------------
##[error]10:35:10.815 ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: java.nio.file.NoSuchFileException: C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp\probe3535171107382725548.pp
Which looks like it’s not parsing “-Ooff” properly. However, earlier in the compile process, though, I get this:
Which is not throwing an error on “-Ooff”. I think that what’s going on here is that the parser is not checking for upper/lower case between “-O” and “-o”. Also, the project is currently generating the makefiles (or whatever it is for CCS) at build time, so we’re not able to directly override that setting at the moment to be the long versions of either one (–opt_level and --output_file). Is this a bug in SonarScanner 4.23.0?
Finally had enough google luck to stumble across this bug, which looks to be the same thing as I’m running into. I believe you are right at this point @mpaladin that upgrade to 8.9 will likely fix it (with the attendant cfamily updates). I will check back in Monday after the upgrade and update this thread with the results. Thanks!
@mpaladin The update did solve the issue, so I will say you were right! Not sure if one of those should be marked as the solution, but either way I think this thread is ready to be closed. Thanks for your help!
Not sure if one of those should be marked as the solution, but either way I think this thread is ready to be closed. Thanks for your help!