Change BuildStepMonitor to allow for higher concurrency

[013k-m]

Jenkins changed getPreviousBuild() to halt jobs if a previous
build hasn't finished, meaning jobs of variable runtime end up
being serialized:

https://issues.jenkins-ci.org/browse/JENKINS-9913?focusedCommentId=184188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-184188

This change switches to the latest completed build, allowing
this plugin to work with jobs of variable length.

This change is made in a same way as for slack-plugin
jenkinsci/slack-plugin@832e7b5

[codecov]

Codecov Report

Merging #19 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master      #19      +/-   ##
============================================
+ Coverage     80.97%   80.97%   +<.01%     
- Complexity     1414     1415       +1     
============================================
  Files           224      224              
  Lines          4735     4736       +1     
  Branches        379      379              
============================================
+ Hits           3834     3835       +1     
  Misses          767      767              
  Partials        134      134

Impacted Files	Coverage Δ	Complexity Δ
...ns/plugins/analysis/core/steps/IssuesRecorder.java	88.23% <100%> (+0.05%)	94 <1> (+1)	⬆️
...s/plugins/analysis/core/util/IssuesStatistics.java	100% <0%> (ø)	16% <0%> (ø)	⬇️
...ns/analysis/core/util/IssuesStatisticsBuilder.java	100% <0%> (ø)	18% <0%> (ø)	⬇️
...ugins/analysis/core/columns/IssuesTotalColumn.java	74.66% <0%> (ø)	12% <0%> (ø)	⬇️
.../plugins/analysis/core/charts/LinesChartModel.java	72.72% <0%> (ø)	8% <0%> (ø)	⬇️
...nkins/plugins/analysis/core/model/DeltaReport.java	100% <0%> (ø)	11% <0%> (ø)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 01301c9...3fedf21. Read the comment docs.

[uhafner]

Does this help anything in your real setup? I think we also need to override

IssueRecorder.getRequiredMonitorService

and return BuildStepMonitor#NONE

[013k-m]

@uhafner yes this issue really blocks usage of this plugin in our setup (with concurrent executors) as each next build waits for a checkpoint (before parsing checkstyle results) for the end of the previous build and execution time of our builds starts to grow like a snowball. For such jobs we have to use old deprecated plugin to parse checkstyle results and it would be really nice to change this.

[uhafner]

@013k-m I understand that it blocks your system. I just wondered if it is already noticeable better using other getters without the BuildStepMonitor change in your system? Did you deploy the change to your machine?

[013k-m]

@uhafner I was checking it in a dockerized jenkins with a pipeline flow and I was not able to reproduce this, but I just rechecked again and it is reproducible only in a normal jenkins job and you are right, we just need to override the buildstepmonitor to fix that behavior. Sorry for that, should I tuneup or recreate this pr?

[uhafner]

Just revert the first commit and push again. Then we have the history and discussion visible in this PR. If we need to change the getters later on as well we know the background discussion in this PR.