Status: Closed (View Workflow)
Environment: Arch Linux 64-bit
JRE: OpenJDK Runtime Environment 1.8.0_242-b08 (from Docker image)
Jenkins: 2.263.1 LTS and 2.274 weekly (issue happens on both versions)
Plugin versions: forensics-api 0.8.0, git-forensics 0.8.1, workflow-job 2.40, workflow-multibranch 2.22, bitbucket 1.1.27
Jenkins installation: official Docker images for LTS and weekly
Freshly deployed Jenkins instance in accordance with https://www.jenkins.io/doc/book/installing/docker/Environment: Arch Linux 64-bit JRE: OpenJDK Runtime Environment 1.8.0_242-b08 (from Docker image) Jenkins: 2.263.1 LTS and 2.274 weekly (issue happens on both versions) Plugin versions: forensics-api 0.8.0, git-forensics 0.8.1, workflow-job 2.40, workflow-multibranch 2.22, bitbucket 1.1.27 Jenkins installation: official Docker images for LTS and weekly Freshly deployed Jenkins instance in accordance with https://www.jenkins.io/doc/book/installing/docker/
I’ve been trying to configure Jenkins for static code analysis with the use of Warning NG and Git Forensics plugins to execute static analysis in a scope of a Docker container (with Checkstyle, PMD and other utilities, as well as their rules bundled in). The idea is to utilize multibranch pipelines, so that when a developer creates a pull request in Bitbucket, Jenkins automatically executes a job for that branch, checks for any new issues reported by code analysis tool and then informs Bitbucket if everything is okay and pull request can be merged. Pretty standard stuff.
- Run a fresh Jenkins instance and install the required plugins (warning ng, git forensics)
- Add new multibranch pipeline connected to Bitbucket Cloud repository (Jenkinsfile in the attachments)
- Scan multibranch pipeline to run the builds for all the branches
However, I’ve come across an implementation which seems invalid and I’m not able to find any workaround for it (hence the major bug priority). For the very first job executed for the branch or pull request, the Forensics API and Warning NG which is using it are not able to figure out what SCM is being used and cannot extract information like who introduced the new code smells:
Then, when trying to mine the repository with mine repository forensics step, I get the following output:
However, on the second run of the very same job, everything works as expected:
The issue is present for the multibranch pipelines not only when Bitbucket Cloud is selected as an SCM but also in case of generic git. The issue doesn’t happen when the standard pipeline (non-multibranch) is used - in its case SCM is properly figured out even during the first build run of the job. Unfortunately, the mentioned use case is not one where a standard pipeline could be used.
I’ve checked the source code of Jenkins and its plugins and also debugged it a bit and here is what I found that causes the issue. In order to obtain the miner and blamer, Forensics API uses helper class called [ScmResolver|https://github.com/jenkinsci/forensics-api-plugin/blob/master/src/main/java/io/jenkins/plugins/forensics/util/ScmResolver.java]. Looks like it has a separate way of figuring out SCM from the freestyle projects (extractFromProject method) and the pipelines (extractFromPipeline method). The latter one gets the SCMs from the job with the getSCMs method from the SCMTriggerItem class. In my case, the instance is actually of a WorkflowJob type and its implementation of extracting SCMs looks as follows:]
I don’t know why it is like that, but figuring out the SCM is made on the base of previously executed builds. This explains why during the very first build it cannot determine the SCM, but on the other hand - couldn’t there be a different way to get that information? I’ve attached the debugger to Jenkins instance and analyzed this snippet of code in the workflow-job-plugin library. I’ve got the following result - WorkflowJob returning empty set of SCMs because there were no builds made before:
On the other hand, looking on the content of WorkflowJob instance, there is a GitSCM instance dangling somewhere in its properties:
It’s in the instance of [BranchJobProperty|https://github.com/jenkinsci/workflow-multibranch-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/multibranch/BranchJobProperty.java] class from the workflow multibranch plugin.
It makes it impossible to simply apply the solution in the form “if-multibranch-then-get-from-property” without diving into reflection mess due to the fact the workflow-multibranch plugin uses workflow-job as a library and has access to its libraries, but not vice versa.
What I think could help is either change how Forensics plugin’s ScmResolver finds out about the multibranch pipeline’s SCM or modify the code in WorkflowJob to not give up in case when there were no jobs executed before and somehow get that information. However, although both solutions could be implemented in such a way that it wouldn’t affect previous behavior, I don’t know which one would be more reasonable to make modifications in.