I have quite a large multi-module multi-language maven project (~100 modules in total), which I want to analyze using SonarQube and since the scanner doesn't automatically discover all files in all languages (i.e. not for Groovy and Kotlin), I have to tell it where to look for the files.
Most module contain the typical combination of a src/main/ and a src/test/ directory but not necessarily both, which makes it impossible to simply declare <sonar.sources>pom.xml,src/main/</sonar.sources> and <sonar.tests>src/test/</sonar.tests> as properties in the top level pom, since the missing directory causes maven to abort with an error.
According to https://stackoverflow.com/a/37545474 one possible solution to this problem is to
set ...
sonar.sources to be .
sonar.inclusions to be src/main/**
=> this will include all the known files that SQ finds in your modules in the src/main folder if it exists
and using just
<sonar.sources>.</sonar.sources>
<sonar.tests>.</sonar.tests>
<sonar.inclusions>pom.xml,src/main/**</sonar.inclusions>
<sonar.test.inclusions>src/test/**</sonar.test.inclusions>
in the top level pom indeed works as expected (all files, that are supposed to be analyzed, are found and no errors are reported because of missing directories) but it also causes the following warning, which shows up in SonarQube as well:
[WARNING] Specifying module-relative paths at project level in the property 'sonar.inclusions' is deprecated. To continue matching files like 'frontend/pom.xml', update this property so that patterns refer to project-relative paths.
All paths I tried so far either cause less files to be analyzed in total or result in an error because individual files would be indexed multiple times, due to non disjoint sets produced by the inclusion patters. Thus the question ...
How do I have to use the *.inclusions properties to get rid of the warning, while still analyzing all files in all submodules?
gresens,
I have the same problem using Jenkins pipeline. I resolved including the "projectBaseDir" parameter, like this:
<properties>
<sonar.projectBaseDir>.</sonar.projectBaseDir>
</properties>
Reference: https://community.sonarsource.com/t/relationship-between-projectbasedir-sources-and-exclusions/12785
Related
I want to ignore test files in codeql result.
but this query includes test files.
import codeql.ruby.AST
from RegExpLiteral t, File f
where not f.getBaseName().regexpMatch("spec")
select t
ignore test files in the result
regexpMatch requires that the given pattern matches the entire receiver. In your case that means it would only succeed if the file name is exactly "spec". Maybe you rather want to test for ".*spec.*" (or use matches("%spec%")).
I am not sure though if that answers your question. As far as I know there is in general no direct way to ignore test sources. You could however do one of the following things:
Exclude the test directory when building the CodeQL database; for GitHub code scanning see the documentation
For GitHub code scanning filter out non-application code alerts in the repository alerts list (see documentation)
Manually add conditions to your query which exclude tests, for example a file name check as you have done or checking the code for certain test-related constructs
Been trying to set up configuration-specific variants of resource .resw files in my project, so I could have have different resource string values in Debug and in Release (and in other configurations).
There are standard facilities in VS to have files conditionally included or excluded from build depending on selected Configuration. I have set up file properties to be Content=Yes and Excluded From Build=No for a file that must be included in a configuration, and the other way around for the other file.
The variants appear as expected in the IDE - only one matching current configuration is active, and another one is shown with Content=False in the Properties view, and with a red icon in the files list. The vcxproj also contains correct PRIResource nodes for .resw files with DeploymentContent and ExcludedFromBuild set:
<ItemGroup>
<PRIResource Include="Debug\Strings.resw">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">false</ExcludedFromBuild>
<DeploymentContent Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">true</DeploymentContent>
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'">false</ExcludedFromBuild>
<DeploymentContent...
Building this project however fails with a message
error PRI277: 0xdef00532 - Conflicting values for resource 'resw
name/resource name'
Examining intermediate files reveals that both .resw variants are listed in resources.resfiles that is then fed into MakePri.exe . The ExcludedFromBuild setting appears to be ignored.
How would I get this to work? Is there a special way to control the inclusion of resw files? Maybe a different approach to having string variants altogether?
There are apparently "qualifiers" for organizing resource variants, and a naming scheme (https://learn.microsoft.com/en-us/windows/uwp/app-resources/tailor-resources-lang-scale-contrast). There is even a "Configuration" qualifier, though it is not entirely clear which configuration that is, and where at run time I am supposed to take an identifier to select a resource variant I want.
Adding this as an answer for the sake of completeness, as this is relevant and might even be useful to someone. But I am not happy with project configuration concerns being displaced to runtime, with unneeded and possibly sensitive values being added to the package. So I decided to force-emulate ExcludedFromBuild and am picking and copying the single .resw variant I need into build via a Custom Build Step. Shout out to whoever is responsible for this awkward mess at Microsoft.
Instead of excluding or ignore rules in sonar's property file, I'd like to have only a few certain rules for sonar to analyse, so I don't need to exclude a large number of rules out of 344 rules for c++. How can I do that? (I'm not adding customized rules)
I imageine the syntax would be: (in .properties file)
sonar.issue.include.multicriteria=***
sonar.issue.include.multicriteria.***.ruleKey=cpp:S984
....
EDIT:
1, I need to configure this in a CLI environment.
2, It's about one project, two rule sets. one rule sets for local use and the other one for CI/CD use.
You need to craft a Quality Profile that contains only your rules of interest, and then either make it the default profile for C++, or explicitly assign your project to it.
BTW, correctly setting exclusions in properties (versus through the UI) is quite tricky. I'm not sure about the correctness of the ruleKey field name, and you're probably missing another field in there, but your syntax seems to be on the right track.
Suppose I have set groupId to com.example, and artifactId to fancy.project, and now I want to create a archetype, such that when created, expands into the following structure:
|--src
|--main
|--com
|--example
|-fancy
|-project
|-App.java
That is, I wonder how to expand a variable into a nested directory.
I understand that the dual-underscore-wrapped variables will be substituted in file/directory names, but I can only get the following with __groupId__.
|--src
|--main
|--com.example
|-fancy.project
|-App.java
As input to the archetype you can specify the package option (which would then follow your input, the groupId and artifactId concatenation if you want, even though it is not always the case and hence provide even more flexibility).
Then, in your archetype you can use the packageInPathFormat option (available since archetype 2.2) which would replace any dot . into slash \ and as such transforming it to a path into the generated project.
However, the option is not officially documented (pity) even though supported and works fine for such a scenario.
Looking at the code, the DefaultFilesetArchetypeGenerator and its getPackageInPathFormat provide the concerned transformation from the package option to a path, while the org.apache.maven.archetype.common.Constants.PACKAGE_IN_PATH_FORMAT is the official entry point for this option.
Some externals pointers on the usage of this option:
http://geekofficedog.blogspot.be/2013/08/creating-maven-archetypes-tutorial.html
http://www.theotherian.com/2012/05/maven-archetypes-part-2-how-do-i-create.html
To further explain:
You can have the __packageInPathFormat__ folder under your src/main/java, for example
The __packageInPathFormat would then be replaced by the package option transforming dots into slashes
The package option has a default value to groupId, so if you don't specify it, for a groupId with value com.sample, the path would be com/sample
You can hence specify at invocation time the package desired via -Dpackage=your.package repeating the values for -DgroupId and -DartifactId (a bit verbose and error prone though), the final result will actually be what you expected (transformed to correct path).
You can specify new default values via a archetype-metada.xml file, as specified in the official documentation, via the requiredProperties section, you could have something like:
<requiredProperties>
<requiredProperty key="package">
<defaultValue>__groupId__.__artifactId__</defaultValue>
</requiredProperty>
</requiredProperties>
However, the generated path would then be com.sample/artifactid rather than com/sample/artifactid. Hence it would not work as expected due to the processing workflow which would replace the placeholders after transforming it to a path (pity!).
(Note: it would transform the dot we provided as configured value, but would then not transform dots into the replaced placeholders).
As of a quick code analysis, seems like the DefaultFilesetArchetypeGenerator class in its generateArchetype method is preparing the context too early (in its prepareVelocityContext method, where the packageInPathFormat is transformed and added to the context), then the context is passed to processArchetypeTemplate* methods which would eventually invoke the Velocity engine (which is going to replace placeholders then). I am not a Velocity expert though, hence I may miss some glue, but the observed behavior and the code workflow seem to lead to this conclusion.
Instead of using the variables __groupId__ and __artifactId__ you can use ${groupId} and ${artifactId} respectively instead (I don't know if these were around when this question was posted), so it would look something like this:
<requiredProperties>
<requiredProperty key="package">
<defaultValue>${groupId}.${artifactId}</defaultValue>
</requiredProperty>
</requiredProperties>
When generating a project using these, in interactive mode it will actually request to enter the package, and in batch mode it will automatically generate CLOSE to what OP wanted.
Ex. groupId being me.zenisbestwolf and artifactId being fancy-app will generate the path of me/zenisbestwolf/fancy-app. Unfortunately automating the artifact ID to go from fancy.app to fancy/app like OP wanted to isn't possible without manually defining the package, AFAIK.
Can you include expressions in the "Output Files" section of a build rule in Xcode? Eg:
$(DERIVED_FILE_DIR)$(echo "/dynamic/dir")/$(INPUT_FILE_BASE).m
Specifically, when translating Java files with j2objc, the resulting files are saved in subfolders, based on the java packages (eg. $(DERIVED_FILE_DIR)/com/google/Class.[hm]). This is without using --no-package-directories, which I can't use because of duplicate file names in different packages.
The issue is in Output Files, because Xcode doesn't know how to search for the output file at the correct location. The default location is $(DERIVED_FILE_DIR)/$(INPUT_FILE_BASE).m, but I need to perform a string substitution to insert the correct path. However any expression added as $(expression) gets ignored, as it was never there.
I also tried to export a variable from the custom script and use it in Output Files, but that doesn't work either because the Output Files are transformed into SCRIPT_OUTPUT_FILE_X before the custom script is ran.
Unfortunately, Xcode's build support is pretty primitive (compared to say, make, which is third-odd years older :-). One option to try is splitting the Java source, so that the two classes with the same names are in different sub-projects. If you then use different prefixes for each sub-project, the names will be disambiguated.
A more fragile, but maybe simpler approach is to define a separate rule for the one of the two classes, so that it can have a unique prefix assigned. Then add an early build phase to translate it before any other Java classes, so the rules don't overlap.
For me, the second alternative does work (Xcode 7.3.x) - to a point.
My rule is not for Java, but rather for Google Protobuf, and I tried to maintain the same hierarchy (like your Java package hierarchy) in the generated code as in the source .proto files. Indeed files (.pb.cc and .pb.h) were created as expected, with their hierarchies, inside the Build/Intermediates/myProject.build/Debug/DerivedSources directory.
However, Xcode usually knows to continue and compile the generated output into the current target - but that breaks as it only looks for files in the actual ${DERIVED_FILE} - not within sub-directories underneath.
Could you please explain better "Output Files are transformed into SCRIPT_OUTPUT_FILE_X" ? I do not understand.