Version: Enterprise Edition Version 8.1 (build 31237)
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’ve adjusted sonar.scm.revision to:
which alters the error seen:
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
@c-jack if the PR had more than a 100 commits, then it could have been this issue - link