Version: Enterprise Edition Version 8.1 (build 31237)
Hi,
I’m trying to set up and test PR decoration using Jenkins and GitHub, in conjunction with the SonarRunner command in a Jenkins Declarative Pipeline.
I’m generally finding my feet with the configuration, but I seem to have hit an issue that doesn’t seem to exist on the internet (at least via Google!)
The “warning” I see, after the Jenkins job has run, and no PR Decoration has occurred is:
Despite the above, the PR does indeed have the commit hash referenced - I’ve double, triple checked.
Sonar analyses the entire branch (rather than just the PR changes), so it’s definitely seeing some code - I have no idea how to tie this together now, as it doesn’t really make a lot of sense.
Has anyone experienced this issue or able to point me in the direction of any further paths to investigate?
I’m not sure why your first attempt didn’t work if the sha1 matched the HEAD of the P/R’s branch in the server. However, using env.CHANGE_ID might not always work because by default Jenkins merges the target to the P/Rs branch, potentially resulting in merge commit that only exists locally. That would be the value stored in CHANGE_ID, and it would not exist in the server.
In your last attempt you are passing the name of the reference, not the actual sha1 of the commit.
I also think that the reference you are trying to use is correct. Locally, with the way Jenkins fetches, the p/r should be in origin/PR-571. But to confirm that, please check your logs where Jenkins is checking out the code.
So if that’s correct, you’ll need to pass the value of git rev-parse origin/PR-571. The name PR-571 can be obtained from the environment variables, for example GIT_BRANCH.
