I am trying to change my Jenkins jobs regarding Sonarqube settings. So I opened my Jenkins job configuration, I am seeing something like this
sonar.issue.ignore.multicriteria=e1,e2,e3,e4,e5
sonar.issue.ignore.multicriteria.e1.ruleKey=squid:S00112
sonar.issue.ignore.multicriteria.e1.resourceKey=**/*.java
I am searching for ruleKey "squid:S00112" in Sonarqube documentation, but I am not able to find any reference regarding that.
I need to add a few more rules to ignore. But I am unable to identify the rules rule-key values (like ruleKey=squid:S00112).
On a SonarQube server, rule key is displayed on the top right corner of the rule description. For example, you can look for squid:S109 in this rule description
SonarQube rule key is composed of repository id : rule id
repository id
Each language analyser create several rule repositories with ids that usually contain the language name, except for the java analyser that oddly use "squid".
For example, this is the list of repository keys existing on sonarcloud.io (source)
LANGUAGE_ID : REPOSITORY_KEY_LIST
abap : abap, common-abap
c : c, common-c
cpp : cpp, common-cpp
cs : csharpsquid, common-cs
css : css, common-css, external_stylelint
flex : flex, common-flex
go : go, common-go, external_golint, external_govet
java : squid, common-java, external_checkstyle, external_findsecbugs, external_pmd, external_spotbugs
js : javascript, common-js, external_eslint_repo
kotlin : kotlin, common-kotlin, external_android-lint, external_detekt
objc : objc, common-objc
php : php, common-php
plsql : plsql, common-plsql
py : python, common-py, Pylint
ruby : ruby, common-ruby, external_rubocop
swift : swift, common-swift, external_swiftlint
ts : typescript, common-ts, external_tslint
tsql : tsql, common-tsql
vbnet : vbnet, common-vbnet
web : Web, common-web
xml : xml, common-xml
rule id
Former rules could have a Pascal Case id like "NoSonar", but now, majority of rules have an id stating by 'S' following by the jira number of the rule from this repository jira.sonarsource.com/browse/RSPEC/
For example, rule id S109 matches with RSPEC-109
Note: rules.sonarsource.com/ also use the RSPEC-109 format in the URL, you could easily convert it to S109.
You can find your ruleKey for specific rule inside SonarQube server.
Steps:
Rules Tab -> Select Specific Rule -> Right top is your RuleKey
In this example, the ruleKey is Web:TableWithoutCaptionCheck
Screenshot:
Related
I'm currently building a FHIR (R4) Server, and i try to implement the following request:
[base]/PractitionerRole?practitioner.active:not=true
I know that active is a Token Param, and thanks to HAPI, i can use the following command :
TokenParam tokenSubject = referenceParam.toTokenParam(myContext);
But sadly, all the modifier part is lost : in my referenceParam, i only have a chain part (active:not), and a value part (true), so i don't have any modifiers, missing, etc..
So when i convert it to a TokenParam, i don't have neither the modifiers, missing, etc ...
So here is my question : Is there a way to have a ReferenceParam that has modifiers?
I would like to have a chain part (active), a modifier (not) and a value (true), as in a real TokenParam
Your syntax looks correct. My best guess is you're using token search directly, instead of as part of a chain.
Token/Identifier alone would be appropriate if you were searching for active directly on PractionerRole.
For example: http://hapi.fhir.org/baseR4/PractitionerRole?active:not=true
However, you're doing a nested search with ?practitioner.active:not=true
Try Search Parameters > 4.5.9 Chained Resource References > Dynamic Chains
For example: http://hapi.fhir.org/baseR4/PractitionerRole?practitioner.active:not=true
NB: active:not=true will return both active:missing and active=false
I have a few different Sphinx projects that I would like to refer to each other locally (no web server). I have separate code + build directories setup for the projects and was trying out intersphinx to solve this requirement.
My questions are:
Is there a better way of referring to two or more local projects within Sphinx?
Is there a way to strip out the second build in the path?
In my configuration file I have:
intersphinx_mapping = {
'doc1': ('../build/doc1',None)
}
so I get no issues in doing a make HTML, however when I look at the reference I've created with :ref:'doc1 info <doc1:label1>' I have in the HTML document:
file:///<root path>/build/**build**/doc1/html/doc.html#label1
So the issue is I get two "build" directory listings - it should of been:
file:///<root path>/build/doc1/html/doc.html#label1.
If I manually do this, it correctly pulls in the document.
I've also tried replacing None with '../build/doc1'. If I drop the build from the mapping I do get an error in finding the objects.inv file for doc1.
I do not want to use absolute path since the end user getting this documentation may see it in another location and I want this to be cross platform...
My directory tree is essentially as follows:
Makefile
build/doc1/html
build/doc2/html
doc1
doc2
As a background, I'm trying this under Cygwin with Sphinx 1.7.5... I haven't tried Linux yet to see if I get the same behavior...
You can set a different path for your target and for your inventory.
Maybe you can try something like:
intersphinx_mapping = {
'doc1': ('../doc1', '../build/doc1/objects.inv')
}
If you want to keep the None, it is also possible to have both:
intersphinx_mapping = {
'doc1': ('../doc1', (None, '../build/doc1/objects.inv'))
}
I am using sonarQube 6.3 and when adding new custom rules for Php or Javascript, they are by default declared as Code smell. I would like to declare them as Vulnerability or bug.
Here is an example of a rule declaration
#Rule(key = "Rule1",
priority = Priority.MAJOR,
name = "Rule 1 sould be used.",
tags = {"suspicious" })
Is there a way to do it?
There is a way to set the rule type using some special tags.
Tag "bug" means type "bug"
Tag "security" means type "vulnerability"
So try for example:
tags = {"suspicious", "bug"}
NB: This is documented in API Javadoc (but hard to find I admit)
I am using TeamCity 9.0.2, and I would like to make a template implement another template, or make a build configuration implement more than one template.
Can this be achieved?
This was not available when you asked the question but since Team City 10 you can now use Kotlin to configure your builds and thus your templates.
From this you can make Templates implement other Templates.
I myself have made Templates inherit from other templates to cut down on reconfiguration time and to not have to repeat myself so many times.
open class TheBaseTemplate(uuidIn: String, extIdIn: String, nameIn: String, additionalSettings: Template.() -> Unit) : Template({
uuid = uuidIn
extId = extIdIn
name = nameIn
/* all the other settings that are the same for the derived templates*/
additionalSettings()
})
object DerivedTemplateA : TheBaseTemplate("myUuidA", "myExtIdA", "myNameA", {
params {
param("set this", "to this")
}
})
object DerivedTemplateB : TheBaseTemplate("myUuidB", "myExtIdB", "myNameB", {
params {
param("set this", "to that")
}
})
object Project : Project({
uuid = "project uuid"
extId = "project extid"
name = "project name"
buildType {
template(DerivedTemplateA)
/* the uuid, extId and name are set here */
}
buildType {
template(DerivedTemplateB)
/* the uuid, extId and name are set here */
}
template(DerivedTemplateA)
template(DerivedTemplateB)
})
The above code might be very hard to understand. It will take some time to familiarise yourself with Kotlin, what it does, and how it interfaces with TeamCity. I should point out that some imports are missing.
Additionally, take the example with a pinch of salt. It is a quick example to demonstrate one way of templates implementing other templates. Do not take this example as the definitive way to do things.
Unfortunately, this is currently not possible but already requested for a long time in TW-12153 (maybe you would like to vote for it).
To share several build steps among several build configurations or build configuration templates, I am using meta runners:
A Meta-Runner allows you to extract build steps, requirements and parameters from a build configuration and create a build runner out of them.
This build runner can then be used as any other build runner in a build step of any other build configuration or template.
Although using meta runners works as a workaround for us, editing meta runners is not as convenient as editing a build configuration template (as it usually requires editing the meta runner definition XML file by hand).
Update 2021
As #zosal points out in his answer TeamCity meanwhile provides another way of sharing common build configuration data or logic by means of the Kotlin DSL. The Kotlin DSL is a very powerful tool but may not always fit in your specific scenario. I would recommend to at least give it a try or watch one of the introductory tutorial videos.
How to use Stanford parser from GATE embedded (using GATE through Java code). I currently use GATE_Developer_7.0 on my machine; i know that there is plugin for Stanford Parser in GATE but don't know how to use it using java code.
Thanks
The usual approach we always recommend for GATE Embedded is to build up your pipeline using GATE Developer, test it out and get it debugged by processing sample documents in the GUI. Once you're happy with the application, use "save application state" or "export for GATECloud.net" to produce a saved state that you can then load in your embedded code using the PersistenceManager. This will automatically ensure that all the necessary plugins are loaded and is generally much simpler and less error-prone than trying to build up your pipeline by hand in your code.
The BatchProcessApp example on the GATE website shows how you can load a saved application with the PersistenceManager, essentially it's
Gate.init(); // always the first thing you do
CorpusController controller = (CorpusController)PersistenceManager
.loadObjectFromFile(new File("/path/to/application.xgapp"));
Corpus corpus = Factory.newCorpus("myCorpus");
controller.setCorpus(corpus);
then for each document you want to process
Document doc = Factory.newDocument(....);
corpus.add(doc);
try {
controller.execute();
// code here to do stuff with the annotated document, e.g. extract
// annotations/features
} finally {
corpus.clear();
Factory.deleteResource(doc);
}