I need to report on build metrics. There is a plugin that offers this information called build-metrics but it does not work with blue ocean.
Has anybody found a way to accomplish this?
I've tried using the Jenkins CLI (version 2.361.2) to get this information. There are a lot of features built into the CLI but I can't figure out how to get the status of all builds that were run over a weekly time frame.
Related
apologies if this has been covered, there have been a couple similar questions on SE - but struggling to find an explicit solution:
Does anyone know how to access the reports from SonarQube? I want to put some logic in Jenkins that will only proceed to do more stuff if quality gates are passed. This is something I wish to automate, and not login to sonarqube manually.
I have seen references to a possible, Gerrit plugin solution or using a curl step to use the API but neither explained how to replicate that approach.
You've got to use the SonarQube Scanner for Jenkins.
Specifically, check the "Analyzing in a Jenkins pipeline" section: it allows you to run a SonarQube analysis, and wait for the Quality Gate to be available so that you can decide (in your pipeline script) what to do based on the status of the quality gate.
sonarqube reports can be extracted using webapi
for example : http://sonarserver:9010/api/issues/search?componentKeys=sonarProject&severities=BLOCKER,CRITICAL,MAJOR,MINOR,INFO&s=SEVERITY&asc=false&ps=100
convert the json output to csv and to xls using online tools
http://convertcsv.com/json-to-csv.htm
I want to test an app on multiple emulators with different screen sizes. I prefer to have just one build plan instead of a build plan for every emulator configuration.
Is is possible to run e.g. 3 emulators with different configurations using Android Emulator Plugin for Jenkins?
Is there some other plugin to achieve this?
Using the Matrix plugin is a good solution for this, as discussed on the wiki page for the emulator plugin.
This lets you have a single Jenkins job, where you define the various configuration combinations you want — Jenkins will then run a series of sub-jobs to fulfil each combination, in turn creating the desired Android emulator config.
My project has about 20 build steps and i want to monitor how much time each step takes over builds. I found Jenkins doesn't display such info.
Can use any of Jenkins tools or plugin to do that?
Was just looking for the same and found your post. There is this plugin though it doesn't show you a nice graph or anything it will add the raw timestamps to your log lines on a per project basis. https://wiki.jenkins-ci.org/display/JENKINS/Timestamper If you install it you have to configure each project separately to check the add timestamps to console box (there is a script for doing all projects at once but I didn't want to chance that and only need it to diagnose a particularly slow build).
Did you try this. Makes sense to your case.
https://wiki.jenkins-ci.org/display/JENKINS/build-metrics-plugin
I set up jmeter job in jenkins, which supposed to publish *.jtl results and then display them in a nice trend graph.
But, depite that I see that they're published under the builds//performance-results/JMeter folders, the trend always shows only current day results. So if I run this build three times during a day - I'll see graph with a three points. If it was just one run today - I'll see 1 run on that graph. I don't see yesterday and etc results on graph. I'd like to see this trend to display all the data from all the previous builds, including yesteday, etc.
What should I check, how perf plugin decides which *.jtl data to use to display data??
in settings of the job I have this regexp for jtl source: **/*.jtl, so I would expect all the builds data being displayed on the trend ...
Apparently the solution is very simple. Found it myself!
By default all jtl files had a timestamp at the beginning, thanks to jmeter-maven-plugin. Pattern was yyyyMMdd. Trend report in jenkins displayed last build results. And because of the pattern jtl results for all builds run this day were the same, and were different for previous day.
So, easiest solution was to remove that timestamp from the results file name.
<testResultsTimestamp>false</testResultsTimestamp>
in configuration part of jmeter-maven-plugin in the pom file.
Annoying, is that Performance plugin guys haven't put it into the documentation, - the requirement for results file to have the same name in order to be displayed on the graph...
Apart from that, there is an issue with Performance plugin (version 1.12 and 1.13). Due to that, the LastReport (image doesn't show) and other reports are showing missing info.
To fix it, either you can download/git clone the latest code from Performance Plugin github repo and build it locally (using mvn clean install and you'll get performance.hpi Jenkins plugin file) OR revert back to Performance plugin 1.11 version.
As 1.12/1.13 have some other enhancements over 1.11, I selected to build myself, until someone will fix Performance Plugin and come up with a recent release version (aka 1.14 containing the fix for this issue).
Issue: https://issues.jenkins-ci.org/browse/JENKINS-27100
The builds in my project have started to take more time recently. I need to optimize them, but I don't want to do blind optimizations. I need how many time is consumed by respective steps of the build process (fetching, preparing, build script, publishing etc). It there any jenkins plugin that enables cuch profiling?
Not really a profiling tool, but you should start with the Timestamp plugin
https://wiki.jenkins-ci.org/display/JENKINS/Timestamper
This will put a timestamp for every line in your console log. You can then easily see how much time was spent on each particular section (checkout, building, publishing) in the log
If your build calls out to standard build tools like Ant, Maven etc., you may want to give YouMonitor a try: https://www.yourkit.com/youmonitor/features/. Be aware this does not show you any details of the Jenkins pipeline or job, but summarizes the external build tools quite nicely by their goals/targets etc.