I've got a jenkins CI installed with the valgrind plugin. There is one very important thing missing there: you cannot set executable options. I can set parameters, but if I want to call valgrind my_executable -opt my_option_value the plugin will generate the command valgrind my_executable "-opt my_option_value" and this is useless.
I found a jira ticket corresponding to this feature. It's stated to be fixed since version 0.12, but I can't see neither in my jenkins (latest version - 1.500 and valgrind plugin 0.18) nor on the main plugin website screenshot.
Does anyone know if the valgrind jenkins plugin supports executable options?
The problem solution is quite obvious - it's just a valgrind plugin bug (it dumps valgring executable options in quotation mark, but it shouldn't). This bug will be fixed in the next release of the plugin (0.19) planned on the end of february this year. See comments on https://issues.jenkins-ci.org/browse/JENKINS-15138 and https://issues.jenkins-ci.org/browse/JENKINS-16123
Related
I just installed "Jenkins Warnings Next Generation Plugin" and was wondering how to use the "SonarQube" Static Analysis Tools there.
I found out, that it will parse the result of "sonar-report.json" but I don't know how this files is being generated.
Looking in the SonarQube Documentation I only found out, that the "sonar-report.json" was generated using the "preview mode" which is deprecated since SonarQube 6.6
Does anyone have an Idea how to generate this file with then newest SonarQube (7.4+) or is the Warnings Plugin for SonarQube useless?
Thanks
As mentioned in SonarSource Community it is possible to generate the sonar-report.json using
sonar-scanner -Dsonar.analysis.mode=preview -Dsonar.report.export.path=sonar-report.json
Nevertheless this parameter is marked as deprecated and should not be used anymore
WARN: The use of the issues mode (sonar.analysis.mode=issues) is deprecated. This mode will be dropped in the future.
I have found a plugin for using StatsD with Jenkins (https://github.com/joemiller/jenkins-statsd-plugin) - however the HPI needs building because it is not available in Jenkins plugin repository nor is it aailable to download.
I followed the official instructions at https://wiki.jenkins.io/display/JENKINS/Plugin+tutorial, but the $ mvn package always exits with [ERROR] java.nio.file.NoSuchFileException: ~/src/jenkins-statsd-plugin/target/classes/META-INF/annotations/hudson.Extension.
I have tried using java 6, 7, 8 and 10 but to no avail.
I wonder if anybody else has come up against this problem building Jenkins plugins and what they're solution was?
I fixed this problem by setting JAVA_HOME to point to Oracle’s version of Java 8. It appears maven uses the JAVA_HOME environment variable, not your $PATH.
Edit: For extra context, Jenv was responsible for the version of Java in my $PATH.
I would like to post here my findings from various sources that worked for me as the accepted answer alone was not sufficient.
I had to downgrade my Java version back to 11 from 13.
I used this quick solution, which doesn't require you having JDK and Maven installed locally.
Moreover, deleting target/classes/META-INF/ directory before executing mvn install again was necessary.
Lastly, passing -Djenkins.version parameter to Maven is required so you need to do something like mvn -Djenkins.version=2.164 install
This will definitely get resolved by using java 1.8.* JDK.
My Jenkins instance interface broken. I suspect recent plugin update as the cause. However I cannot remember which plugins get updated recently. I need to know so I can rollback plugin version to the previous one.
How to find this information?
Some possible way:
Jenkins log
Retrieving plugins info via Groovy console
In my opinion, the most efficient way is go to the $JENKINS_HOME/plugins directory, then issue command:
ls -alt *.hpi *.jpi
and the most recently update/installed plugins are ranking at the top of the results, hope this helps.
Create a job scheduled to run daily, that logs the plugins and versions. There are several ways to do this, and it seems that none are straightforward or obvious. The method I've settled on simply archives the output file of this command:
curl -kLsS "${JENKINS_URL}pluginManager/api/json?pretty=1&tree=plugins\[shortName,longName,version\]" \
> plugin-list.txt
That give an easily accessible history from the Jenkins web UI. (Or on-disk if you know where to look.)
Diffs comparing previous version(s) left as an exercise for the reader.
After upgrading my jenkins install on ubuntu using ubuntu packages, I'm getting an error with the cloudbees licence plugin.
java.lang.NullPointerException
at com.cloudbees.jenkins.plugins.license.BootHook.innerOnLoaded(BootHook.java:59)
at com.cloudbees.jenkins.plugins.license.BootHook.onLoaded(BootHook.java:49)
at jenkins.model.Jenkins.<init>(Jenkins.java:845)
at hudson.model.Hudson.<init>(Hudson.java:81)
at hudson.model.Hudson.<init>(Hudson.java:77)
at hudson.WebAppMain$2.run(WebAppMain.java:214)
My jenkins version is 1.492
If I disable the plugin, that works, but I cannot see some project that are in folders.
How can I do ?
A change in core affected the plugin.
Briefly, there is a conflict between versions of Bouncy Castle in core and the plugin. As the plugin has to support a wide range of Jenkins versions, it includes a version of Bouncy Castle, and requests that this be loaded in an isolated classloader... Under certain circumstances core will resolve the classloaders differently when looking for extensions, and the extension can end up resolving a different version of Bouncy Castle... which results in the extension (free-license-plugin) not being found, and the corresponding NPE.
We fixed this issue a couple of days after 1.490 was released. The fix is in cloudbees-license 3.5 and free-license 3.2 (also in nectar-license 3.3 - but that is only of relevance if you are running any of the Jenkins Enterprise plugins)
To get a borked system back to working here is the set of steps to follow:
Stop Jenkins (if you haven't already)
Remove the following directories $JENKINS_HOME/plugins/cloudbees-license, $JENKINS_HOME/plugins/free-license and if present $JENKINS_HOME/plugins/nectar-license
Remove the following files $JENKINS_HOME/plugins/cloudbees-license.hpi, $JENKINS_HOME/plugins/cloudbees-license.jpi, $JENKINS_HOME/plugins/free-license.hpi, $JENKINS_HOME/plugins/cloudbees-license.jpi, and if present $JENKINS_HOME/plugins/nectar-license.hpi or $JENKINS_HOME/plugins/nectar-license.jpi (Note: normally there will only be either the .hpi or the .jpi file present. Which is present depends on what version of Jenkins was installed when you downloaded the plugin originally. It doesn't matter which.
Download the latest versions of the plugins that you removed: (Note: only download the nectar-license plugin if you removed it in steps 2 and 3)
cloudbees-license
free-license
nectar-license (only if needed)
It is up to you whether you rename the .hpi to .jpi. Jenkins will pick it up either way, but for longer-term compatibility I would recommend renaming them to the .jpi extension.
Start Jenkins
Do the funky-chicken dance
I have the problem that the code coverage for some reason aren't presented in Sonar.
The result of the unit tests is performed and showed correctly but not the result of the code coverage. The project is build by Jenkins. I have registered the opencover.profiler.dll file as suggested in some threads but still I get no result. Neither I get any error messages in Jenkins when performing the build.
I would be most grateful for any tips on what to do.
Best regards Dan
I think this happens because your Jenkins service is running as "Local System account", but Sonar is running OpenCover with the -register:user switch under the hoods. You should be able to bypass this either by running the Jenkins service as a regular user account, or patch the Sonar-runner to omit the -register:user switch.
It turned out however that the PDB-files caused the problems. They were included in the repository and were for some reason not recreated by the build in Jenkins. The PDB-files therefor contained the wrong path to the actual code files.
Thanks for the help!
Check for version conflicts between OpenCover and the Gallio plugin.
I found that the later versions of OPenCover (starting with Version 4.0.1229) inserted a new tag in the coverage-report.xml file - which the Gallio plugin could not understand. When I rolled back to an older version of OpenCover (4.0.804) the coverage worked again.
You can find more details on http://sonar.15.n6.nabble.com/coverage-report-xml-is-generated-but-sonar-says-coverage-is-0-td5008850.html
It looks like the Gallio plug-in has been updated, but I haven't pursued that yet (wanted to first confirm that this was the cause of the problem).