How can I publish the results of the code coverage to the trend graph even if the job fails after the jacoco analysis?
For Findbugs, PMD, etc. this can be achieved with the canRunOnFailed setting. Is there something similar for JaCoCo?
On project level I see the trend graph which only considers the successful builds. I would also like to see the coverage graph updated if the job fails.
This is tracked by JENKINS-28479:
ProjectActions (and trend graphs) do not appear for failed projects
This problem is not only related to the JUnit plug-in. In general, every plug-in that has been migrated its actions to a SimpleBuildStep has this problem. The affected source code is in SimpleBuildStep.
A test case that exposes this bug is WarningsPluginTest#should_not_skip_failed_builds_with_option_run_always
This is still open.
Original answer:
This is not specific to the maven jacoco build step: all you need to do is make sure that build step always return "success".
If you are using pipelines, you can wrap your step in a try/catch.
If you are using a regular job definition, you could consider a shell/windows command step where you return 0 (or exit /b 0) after the mvn command.
The next build step would be the mvn sonar:sonar publication one, which will then always be executed.
Related
Cannot detect file type because of error, and : Failed to copy Build step 'Publish Performance test result report' changed build result to FAILURE Finished: FAILURE. whenever i run the script always i face this..
Take a look into Jenkins Console Output - it should give you the reason for the failure.
Most probably the Performance Plugin fails to find JMeter's .jtl results file in Jenkins Workspace, either the .jtl results file is missing or you're pointing the Performance Plugin to the incorrect location.
If you have a Script step to run a JMeter test like:
jmeter -n -t test.jmx -l result.jtl
You should be able to use simply result.jtl in the Performance Plugin.
Check out:
Performance Trend Reporting
How to Use the Jenkins Performance Plugin
and Running Performance Tests articles for more details on various aspects of Jenkins Performance Plugin use cases.
The Setup - A jenkins job using jenkins parameters testApp and testEnv. The Execution Batch looks like this:
C:\jmeter\apache-jmeter-3.2\bin\jmeter.bat -n -t
C:\JMeter\Scripts\API_scripts\%testApp%.jmx -Jtestenv=%testEnv% -JtestApp=%testApp% -JtestBrowser=NA -l
C:\AUTO_Results\jtl\%testApp%_%testEnv%.jtl
Post-build Actions
Console output (build lob) parsing with a global rule so that the Failures that are logged in the Jenkins Console window will consider the JMeter script failing. (discussed Jenkins shows JMeter script failure even though the script actually passed)
Triggered parameterized build - this is a separate jmeter script that updates a wiki page with either PASS/FAIL and uploads the JMeter report.
The Issue - How do I get the downstream Triggered build to use the parameters from the upstream script? I set the Parameter = Current build parameters but it's not applying those. Also, I wont know the value of the testResult parameter until the upstream build finishes. I tried adding %testResult%=PASS to the 'Predefined parameters' box
As per Parameterized Trigger Plugin page:
The parameters section can contain a combination of one or more of the following:
a set of predefined properties
properties from a properties file read from the workspace of the triggering build
the parameters of the current build
Subversion revision: makes sure the triggered projects are built with the same revision(s) of the triggering build. You still have to make sure those projects are actually configured to checkout the right Subversion URLs.
Restrict matrix execution to a subset: allows you to specify the same combination filter expression as you use in the matrix project configuration and further restricts the subset of the downstream matrix builds to be run.
So you basically need to copy over the parameters you would like to have in the "downstream" job from the current one.
As a workaround to current performance plugin limitations you can consider running JMeter using Taurus tool as a wrapper, it has flexible and powerful pass/fail criteria subsystem which will basically return to Jenkins non-zero exit code triggering build failure in case of issue in the test. If everything goes well Taurus exit code will be 0 which is considered successful by Jenkins. Check out How to Run Taurus with the Jenkins Performance Plugin article for more details.
I currently have a project that I'm using pylint and pytest. I use Travis to validate my build, and also run pylint to verify the code quality.
But I wanted to do something different and not finding anywhere about how I should proceed. I want my Travis build to break if the code rating is below 9.5, not even running the pytest script. Therefore I can guarantee that all the guidelines are being followed.
What can I do to trigger this? Do I have to configure my .travis.yml or pylintrc?
I see two ways to go about this:
write your own reporter for pylint that exits with something non-zero when the report score is below the threshold. custom reporter
hook into/extend the pytest-pylint plugin. Which already has programmatic access to the linter run. pylint-pytest code (runs before the actual pytest tests)
I'm going through the tutorial on YSlow and Phantom js in Jenkins here: http://yslow.org/phantomjs/
Everything appears to be working great except the Jenkins builds are failing. I think this is due to the violations that YSlow is finding (6 for the particular site I am measuring). I'd rather have the build be successful (or unstable) vs. failed though
Is that possible with this or will I have to resort to something like the postgroovy or text finder plugin?
This is the console output:
phantomjs.exe yslow.js -i grade -t 50 --format junit http://www.somesite.com 1>yslow.xml
D:\Apps\Jenkins\workspace\YSlow_Test>exit 6
Build step 'Execute Windows batch command' marked build as failure
Thanks
Any non-zero exit code at the end of your Execute Windows batch command build step will result in build step being marked as failure.
To have the build step marked as success, you need an exit code of 0. I don't know anything about "yslow" or "phantomjs" and why they are giving you exit code of non-zero, but from "batch" side of things, you need only write exit 0 at the end of your build step if you want to overwrite the exit code of your phantomjs command.
You can then use Text Finder plugin to parse the console log and mark build as unstable when certain conditions are met.
Reading over this answer, Configuring yslow on Jenkins looks like you need TAP plugin to have the functionality of unit testing marking the build as unstable automatically
So we have Checkstyle, PMD, Findbugs as tools which performs static code analysis or work on bytecode to find various issues in code and using them in Jenkins/Hudson (under Post build actions), can turn a build to a unstable, failed, successful build depending upon what threshold values we set there.
As SonarQube is the upcoming/future single dash for showing all such analysis in one page for a project/module, I was wondering where in SonarQube settings (I can set such threasholds) to make a build as a failed, unstable, successful i.e. Jenkins will launch the build (ANT/Maven/Gradle etc), calls, sonarRunner (task in Gradle) / sonar-runner (executable in Linux/Unix), then if threasholds are not good, then Jenkins will mark the build as unstable/failed/successful depending upon the set threashold values.
Any ideas?
See alerts / Quality Gates section in SonarQube.(http://docs.codehaus.org/display/SONAR/Quality+Profiles#QualityProfiles-alertsEditingAlerts) and Build Breaker plugin (http://docs.codehaus.org/display/SONAR/Build+Breaker+Plugin).