When building a Change Request build in Jenkins (where I have set Jenkins to merge the target with the source), Jenkins creates a new commit for that merge. I will submit a ticket with Jenkins regarding this, but is there a way to send the original commit id to sonarqube so that the annotations show up in bitbucket correctly?
My current workaround is to manually checkout the source branch and then merge the target with a ‘–no-commit’ which is messy and prone to bugs.
I want the merge because duplications frequently show up when merging code from two branches both into the same target (yes, its a project design problem too…). Developers don’t check build statuses/quality gates after the merge and the failure doesn’t propagate to the new short-lived branches.
I have the same problem and even after getting it done to ‘show’ sonarqube the correct commit id, no pull request decoration happended (see Decorate PR analysis to Bitbucket Server failed)
The only thing I am doing right now is manually doing a very messy and error-prone set of steps:
bat script: "git fetch origin ${env.BRANCH_NAME}"
bat script: "git fetch origin ${env.CHANGE_TARGET}"
def revision = bat returnStdout: true, script: "git rev-parse origin/${branch}"
revision = revision.trim().readLines().drop(1).join("").trim()
bat script: "git checkout origin/${env.BRANCH_NAME}"
bat script: "git merge origin/${env.CHANGE_TARGET} --no-commit"
I then use the revision var in the sonar.analysis.scmRevision key.
It seems that Jenkins gets confused on fetch heads quite frequently as I had to manually delete some existing folders. This has improved since I started letting Jenkins name its job folders (this previously didn’t work as the folder name overflowed and caused a path length error on windows)
this sounds really great for me, many thanks.
Does this also solve the my problem about bitbucket-server (see Decorate PR analysis to Bitbucket Server failed)
Although I was able to give the sonar-analysis the correct git-sha, I’m still getting the error “Failed to create Bitbucket Server Quality Report for commit SHA” (within SonarQube UI when looking at the PR result)
I’m not sure whether it will or not. That change pulls the commit id from the environment. The question is whether the env value gets changed or not when you do the merge. This is probably something we should take up in the other thread, but my question is why you’re having Jenkins do a merge. It seems to me that the branch author should be keeping it up to date so that no merge on the Jenkins side is required.
I happy about dealing the topic within the other thread.
About the Merge on Jenkins:
This merge is nothing, which lasts permanently. Jenkins is doing this merge as we configured the Bitbucket Branch Source Plugin to Merging the pull request with the current target branch revision - just for the moment of build. This merge never makes it’s way into our git repository. With this we can guarantee, that the target branch will never break after a PullRequest was merged. (our policy is, to have explicit merge commits for each finished feature branch instead of trying to see only fast-forward merges; this also matches to our way how we use the BitBucket auto-merge feature). One (small) downside of this setting is, that for each commit, which is done on a target branch, each pull-request pointing to this target branch needs to be re-build by Jenkins.
As far as I can see, this way of using Jenkins does not change the env values you may rely within SONAR-11950 or SONAR-11853
For the record, looking at replies in this thread makes me thing what I said about your merge may be wrong.
This (from that^ thread) may help:
To decorate the PR, Bitbucket REST API is expecting us to pass this commit sha1.
That’s why we have another property, used by our Bitbucket Pipelines integration: -Dsonar.pullrequest.bitbucketcloud.triggerCommit=the_sha1_of_the_branch_head
Depending on what you do in your Jenkins, you may have to also pass it.
I see that 7.8 has been released, but I didn’t see any mention of the ticket above.
I ran some analysis and I am still getting the wrong commit hash sent to sonarqube.
Was this specific to GitHub only, is there a new parameter that I need to set manually, or should I just be looking at our bitbucket merge strategies to change them to be compliant with sonarqube expectations? (I think that --ff-only would resolve this and allow sq to be a quality gate while getting the correct commit hash)
I think it is the field in the webhook payload. I expected, based off the writing in the ticket, that it was to correctly identify the revision from Jenkins as the revision prior to the throw-away merge commit. I will admit that I am not sure how to check the value in either of the locations you listed…
I still received an error in the analysis (PR decoration specifically) saying that it couldn’t find the revision that matched the throw-away commit rather than the correct commit matching the branch HEAD.
You can see in the images below that our PR/branch HEAD is at ba96aba. Because we allow fast-forward, we want to merge the target before testing. This generates commit 12ef7441 which is incorrectly sent to sonarqube. The merge is a setting in Jenkins.
My change was rejected, for good reasons. The initial direction suggested by J Glick was a dead end. See the final comment here for the only possible change that would make sense on Jenkins side:
The new suggested solution would be to use reflection in the withSQEnv build step to extract from Bitbucket or GitHub plugins the sha1 we need. But that look very fragile and hacky, so the priority is quite low on our side for now.
