Upgrade Sonarcloud Functionality #114
Conversation
RReichert
force-pushed
the
rodrigor/integrity-unit-tests-framework-2-extension
branch
3 times, most recently
from
bcd0bd9 to
d7b0da9
Compare
RReichert
force-pushed
the
rodrigor/integrity-unit-tests-framework-2-extension
branch
from
d7b0da9 to
039d8fa
Compare
RReichert
force-pushed
the
rodrigor/integrity-unit-tests-framework-2-extension
branch
from
225a763 to
24bf5da
Compare
RReichert
force-pushed
the
rodrigor/integrity-unit-tests-framework-2-extension
branch
2 times, most recently
from
745a58f to
b4c3eec
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
RReichert
changed the title
|
Kudos, SonarCloud Quality Gate passed!
|
| @@ -51,10 +51,10 @@ lint: | |||
| min_statement_spacing: 1 | |||
| max_statement_spacing: 2 | |||
| max_returns: 6 | |||
| max_branches: 30 # Default target: 12 | |||
| max_branches: 40 # Default target: 12 | |||
There was a problem hiding this comment.
there is some cmake linting which is failing due to SwiftTarget .cmake having too many if statements in the function.
| @@ -182,7 +182,7 @@ macro(swift_collate_arguments prefix name) | |||
| endmacro() | |||
|
|
|||
| function(swift_add_target target type) | |||
| set(this_option INTERFACE OBJECT STATIC SHARED MODULE) | |||
| set(this_option INTERFACE OBJECT STATIC SHARED MODULE SKIP_COMPILE_OPTIONS) | |||
There was a problem hiding this comment.
This flag here is introduced to allow Orion + friends to use this function. To allow us to slowly transition all their code to use these swift_add_* function. Currently they are not as pedantic about things as we are in Starling
| BRIEF_DOCS "Swift target type" | ||
| FULL_DOCS "Identical use as SWIFT_TYPE except that this applies to ALL target types, including INTERFACE") | ||
|
|
||
| define_property(TARGET |
There was a problem hiding this comment.
I'm currently not using this property at the moment.
I originally implemented (accidentally) an alternative solution to swift_list_targets (only after reviewing my code today did I realize that that function already existed) which used a GLOBAL property to accumulate out all registered Swift executables/libraries/etc (see this.) I used this target property to filter the results for specific projects, which in this case did much what ONLY_THIS_REPO did, without using the third_party folder approach. Either way, I believe this might serve some use in the future and might not be bad for reporting purposes so I kept this around.
| define_property(TARGET | ||
| PROPERTY INTERFACE_SWIFT_TYPE | ||
| BRIEF_DOCS "Swift target type" | ||
| FULL_DOCS "Identical use as SWIFT_TYPE except that this applies to ALL target types, including INTERFACE") |
There was a problem hiding this comment.
SWIFT_TYPE wasn't including interface libraries, this is a work around solution. See https://stackoverflow.com/questions/68502038/custom-properties-for-interface-libraries
| if(NOT ${type} IN_LIST x_TYPES) | ||
| continue() | ||
| endif() | ||
| endif() | ||
|
|
||
| if(x_SWIFT_TYPES) | ||
| get_target_property(type ${target} SWIFT_TYPE) | ||
| if (type STREQUAL "INTERFACE_LIBRARY") |
There was a problem hiding this comment.
previously if the target was an interface library (ex eigen) type, cmake would complain about not being able to obtain any properties that didn't prefix with INTERFACE.
| # references to relative paths. This manual step can be done easily with the | ||
| # following Linux command: | ||
| # | ||
| # sed -i -E "s|^(\s+)(${PWD}/)|\1|g" 'sonar-project.properties' |
There was a problem hiding this comment.
I know this is a one liner but I think it would be good to make it available as a bash script, and have pipelines use the bash script to fix up the paths rather than writing this snippet directly into pipeline scripts.
Changes
I've now introduced a new function
generate_sonarcloud_project_propertieswhich no longer requires engineers to explicitly update the sonar-project.properties file whenever they introduce a new project or testing folder. This body of work now means as long as engineers call theswift_add_executable,swift_add_testand/orswift_add_libraryfunction, sonarcloud will now know which source/test files to analyze. It will exclude all other files which are deemed non production code.Future Work / Justification
Look we could have just kept the
sonar-project.propertiesfile system as it was, but in all honesty that lead to engineers forgetting to update the sonar cloud properties files (see here for a list of missed projects). These changes also means that we can easily now develop a system which can correctly calculate the true code coverage for our Swift products by running all unit tests from Starling down to libswiftnav and aggregating the results into a code coverage report (not currently possible but the development of this system is easier now that we have this).Testing