New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add build and vars scripts to support building with sonarqube analysis #797
Conversation
…g with sonarqube analysis
) | ||
) | ||
|
||
%BUILD_WRAPPER% msbuild dokan.sln /p:Configuration="Win10 Release";Platform=x64 /t:Rebuild !CI_BUILD_ARG! || goto buildfailedsys |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not cross-checked this, and my batch-skills became a bit rusty over the years: Can we somehow share some code with build.bat?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually wrote this to do exactly the same as build.bat if it doesn't have the SonarQube variables set, which means "if sonarvars.bat doesn't exist". (I could rem out the SET commands in sonarvars.bat so that they wouldn't run, but it would make things more difficult if people didn't already understand that they needed to remove the REM statements. That's why I didn't offer a patch to overwrite build.bat.)
What I did was take build.bat and add a bunch of variable setting and checking. I also added %BUILD_WRAPPER% invocations before the 'msbuild' lines, because if you don't run it through the build wrapper then SonarScanner doesn't capture the output to figure out what it's supposed to analyze. (if %BUILD_WRAPPER% isn't set, then it expands to an empty string, so the msbuild command becomes the first thing on the line.)
Theoretically, it might be possible to share code with build.bat. It would require changing the order of the builds in build.bat (because of SonarScanner's ordering issue and the sys/ directory not being compiled in the non-version-specific msbuilds), and would require some fancy string matching in a FOR loop (so that only lines that start with "msbuild" would be invoked). It would also be lot more difficult (read: I personally can't figure out a way) to separate out the non-version-specific builds for general analysis and the version-specific builds for sys/ directory analysis. Input on how to accomplish it would be appreciated, since sys/ directory analysis is a concern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @kyanha,
I agree with @Rondom it is a good idea you have but it share too much code with build.bat
. We do not need to stick with batch code.
What could be done is to move build.bat
and dokan_wix
in scripts folder. Rewrite them in powershell to use helpers (build_helper.ps1
) to avoid duplicate codes like vswhere / foreach build configuration and platform, .... Even create a coverity build script that use/download official tools instead of coveritypublisher #665
Like that appveyor script would be smaller and only set the needed env variables for coverity / sonar like you did with sonarvars.bat
and call our build scripts.
Rewrote in ps here: bd8eb71 |
Checklist
Changes proposed in this pull request:
If documentation needs to be added to explain what needs to be changed to get it to work (basically, sonarvars.bat needs to be modified to plug in the correct values available from e.g. sonarcloud.io), I'll happily write it. Also, sonarvars.bat is a separate file so that it can perhaps be added to .gitignore so that secrets don't inadvertently get put in public repositories, while allowing the main logic of the script to be updated as appropriate.