Checkstyle Magic Number settings in SonarQube 4.4
In the documentation above, it says that having a comma separated list eg: "1,2,3,4,5" for ignoreNumbers will work. However, when I try to list out the numbers in a comma separated fashion, it fails. The only way I have gotten it to work is setting ignoreNumbers as a single integer.
This is a known bug that affects the Checkstyle plugin with SonarQube 4.4+ versions.
Feel free to watch and vote for it: SONARCHKST-5
Related
I want to use the maven-release-plugin to release my application. However,
I found that the user input is not very securised. I want to know if it's possible to do as parameter :
type patch to increment last number version (1.0.X+1)
type minor to increment middle number version (1.X+1.O)
type major to increment first number version(X+1.0.0)
Avoid putting 0.0.4 when the 0.0.5 is already released
You can let Jenkins construct the command line parameter -DreleaseVersion for you. The build-helper plugin with the goal build-helper:parse-version allows you to get a lot of useful Maven properties, including the actual and next number for major, minor and incremental.
Context:
We build our maven apps in which version number is injected by a build.properties file. Problem with this approach is that for every release, version number needs to be bumped manually.
Browsing online to fix this problem, i bumped into version number plugin which offers some cool ways to fix the issue.
For instance -Dproject.version=${BUILD_YEAR}.${BUILDS_THIS_YEAR} will solve the issue for me
Problem
I have issue setting up the values for the defined variables
Quoting from the doc:
Initialization Values
Before the build is started, the number of
builds this year / month / week / day can be specified on the command
line or via the job's plugin-configuration web-GUI. If they are
specified, then they will override whatever values are currently in
production. This allows you to migrate your version number from
another system to Jenkins if you choose to do so.
Additionally, it is possible to automatically override the number of
builds this year / month / week / day with values taken from
environment-variables. Instead of just providing a simple number in
the form-fields of the job's plugin-configuration which overrides the
value for the next build (as described above), you can instead provide
an environment-variable whose value will be extracted and used during
the next builds. If it is not set or its value is not convertible to a
positive integer (without loosing precision), the value of the
previous build will be taken instead and increased by one (as is the
standard behavior).
In the last sentence, it says
If it is not set or its value is not convertible to a positive integer (without
loosing precision), the value of the previous build will be taken instead
and increased by one (as is the standard behavior)
So, going by this i built an jar with injected values of BUILD_YEAR and BUILDS_THIS_YEAR, worked as expected (jenkin says Building my_app_2019.1-SNAPSHOT). After that, i removed the variables assuming that they would be picked but unfortunatley jenkin says Building my_app_${BUILD_YEAR}.${BUILDS_THIS_YEAR}-SNAPSHOT.
There is no relevant doc around this or may be i have missed something totally obvious
Question
How do i ensure these var are injected correctly in my maven builds? or rather how do i populate the values using the plugin?
This is not a jenkins pipeline, its a simple jar builds.
Missed setting up Create a formatted version number as below :
updated as per image above and changed command to -Dproject.version=${VERSION_NUMBER}-SNAPSHOT.... voila!!!!!
By that, I mean the built-in bash string operators ${lowercase^^} and ${uppercase,,}. I just wondered what the minimum version is that supports it. Googling indicates version 4.x. But what is version .x? Version 4.3.1 or 4.0?
There doesn't seem to be a change log on http://www.gnu.org/software/bash/
It's added in 4.0. See the NEWS file in Bash source code:
This is a terse description of the new features added to bash-4.0 since
the release of bash-3.2. As always, the manual page (doc/bash.1) is
the place to look for complete descriptions
... ...
hh. There are new case-modifying word expansions: uppercase (^[^]) and
lowercase (,[,]). They can work on either the first character or
array element, or globally. They accept an optional shell pattern
that determines which characters to modify. There is an optionally-
configured feature to include capitalization operators.
Some lines of codes don't need to be checked by Sonar (Sonarqube.org). How can I just disable checking on these lines? Is there any way like just addding annotation "#" to make these lines invisible for Sonar? Thank you!
There are several ways. See FrequentlyAskedQuestions-NOSONAR and further down that page to see both a comment (//NOSONAR) and annotation (#SuppressWarnings) options, as well as some other ways to disable checking.
From official docs:
How do I get rid of issues that are False-Positives?
False-Positive and Won't Fix You can mark individual issues False Positive or Won't Fix through the issues interface. If you're using
Short-lived branch and PR analysis provided by the Developer Edition,
issues marked False Positive or Won't Fix will retain that status
after merge. This is the preferred approach.
//NOSONAR Most language analyzers support the use of the generic mechanism: //NOSONAR at the end of the line of the issue. This will
suppress the all issues - now and in the future - that might be raised
on the line.
We're just switching our metrics gathering to sonar. We previously used sloccount to get the lines of code and are now using sonar but the counts are coming up as around 40% different. Does anyone know what the differences are and if there is any configuration that I should do in sonar to align the two?
On sonar side this is pretty simple : each line containing a character which is neither a blank character or a character part of a comment is considered to be part of a line of code and there is no way to tune this behavior.