Is it possible to display quality gates for pull requests only taking account the code that was added or modified in that pull request? The current “new code” approach is not serving us well. For example with a 30 day window:
It sounds like a Number of Days New Code Period isn’t serving you well. Luckily you have other options.
Yes, but all options are temporal and none of them allow us to show metrics only for code that the PR touched.
To be clear – the New Code Period only affects the Main Branch and any long-lived branches, when analyzing Pull Requests (seen in the Pull Requests section of your project), New Code is defined as what changed in the Pull Request. Nothing more (or less), and isn’t time based.
Sounds like we have a bug in our system then because our pull request analysis uses the same “new code” definition as long lived branches. What’s the best way to get support for private repos on paid subscriptions?
I would suggest sharing screenshots that show the problem here and masking any sensitive details as necessary. This community is the place where SonarCloud is supported.
What parameters are required for new code to work correctly for PRs? We set the following analysis parameters described here:
/d:sonar.pullrequest.key=1234
/d:sonar.pullrequest.branch=feature
/d:sonar.pullrequest.base=main
It seems that new code works correctly with the automatic detection, but it does not when the parameters are set manually. Note that comments are posted on pull requests correctly, it’s just the analysis scope that’s incorrect.
Hey there.
Those are the correct parameters, but you may not be setting them correctly. If automatic detection works, why set them manually at all?
We have some jobs that run using GitHub Actions that use automatic detection and some jobs that run using Jenkins where we manually supply the parameters.
I suspect that the issue is that GitHub Actions builds the PR using the latest commit of the PR (called the PR head). However, our Jenkins jobs are configured to run the builds by merging the target branch into the PR first (called the merge head):
Could this mess with detecting what “new code” is in the PR?
I kept digging and both GitHub Actions and Jenkins is building the merge head. SonarScanner can detect the merge head correctly in the repo checked out by GitHub Actions:
DEBUG: Opening pack index <repo>/.git/objects/pack/pack-1ff326c93e51b12cbf22891258fdfbdbc7e2b628.idx, size 30.540 MB took 128 ms
DEBUG: Merge base sha1: 1cdd1ff2d79c2f46df25f8e05dca188996347ea3
INFO: SCM collecting changed files in the branch (done) | time=491ms
DEBUG: SCM reported 59 files changed in the branch
But it fails to do so with the Jenkins repo:
DEBUG: Opening pack index <repo>/.git/objects/pack/pack-de250b676de0b186a1ac2cf6e2b5aadd7ac964df.idx, size 0.018 MB took 3 ms
DEBUG: Opening pack index <repo>/.git/objects/pack/pack-310c4ecd78636929c2400e41cc4b3570e05322b8.idx, size 0.247 MB took 3 ms
DEBUG: Opening pack index <repo>/.git/objects/pack/pack-e82600f5d29ad1d86ca2f40340ae0c17477601fe.idx, size 30.376 MB took 68 ms
DEBUG: Merge base sha1: 7d96b9f96d8bb763c8d4e8e6b75db58ab9fe7c89
INFO: SCM collecting changed files in the branch (done) | time=622ms
DEBUG: SCM reported 681 files changed in the branch
1cdd1ff2d79c2f46df25f8e05dca188996347ea3 is the merge base. 7d96b9f96d8bb763c8d4e8e6b75db58ab9fe7c89 is a commit from 12 days ago.
In both cases the exact same commit is checked out:
git checkout --progress --force refs/remotes/pull/14551/merge
HEAD is now at 2dcaa1d7d5e Merge c59cefbf3ba760722b473f2100e0d8cbce0e4101 into 1cdd1ff2d79c2f46df25f8e05dca188996347ea3
git log -1 --format='%H'
'2dcaa1d7d5ee58b03f586f5c758015486d014b27'
It appears that SonarScanner picks up an outdated local ref for the target branch instead of the up to date remote ref:
git show-ref master
7d96b9f96d8bb763c8d4e8e6b75db58ab9fe7c89 refs/heads/master
1cdd1ff2d79c2f46df25f8e05dca188996347ea3 refs/remotes/origin/master
@Colin Can you file a bug report about this?
Hey @Nezz
Thanks for the follow-up – it makes sense now why you are manually configuring things since you are using Jenkins.
I suspect that GitHub Actions vs. Jenkins are checking out the code differently. Could you try executing a git fetch --all? See this thread, where a (SonarQube) user faced a similar issue.
Hi Colin,
Yes, they are checking out the code differently. As I described above, the issue is that there are local references in git and remote references. The remote references are updated by git fetch, but SonarScanner first tries to find a local reference with the same name, and if that doesn’t exist then it looks for remote references.
When we use GitHub Actions, then there are no local references.
When we use Jenkins, there are some local references. The same happens in the real world on developer’s machines. Here’s a simple reproduction:
# Clone the repository, this will check out the default branch (e.g. master)
git clone repository
# Reset master to the previous commit locally
git reset --hard HEAD~1
# Check out a feature branch
git checkout origin/feature
# Run SonarScanner
dotnet sonarscanner begin \
/d:sonar.pullrequest.key=1234 \
/d:sonar.pullrequest.branch=feature \
/d:sonar.pullrequest.base=master
dotnet sonarscanner end
# Notice that SonarScanner will log that "Merge base sha1" is
# where the local master branch is pointing, not the remote one
Just noticed this thread, and want to add that we faced the same issue recently. It made us remove the coverage from quality gate entirely since it’s absolutely not useful like this.
In that project we are using the Teamcity SonarQube Runner to run the analysis and a git repo as VCS.
Hey @Nezz
Sorry for the late response.
Could you try changing this setting to The current pull request revision and see if it affects the behavior?
Hi,
the default AzureDevOps integration has the same issue for PRs.
In my PR I only changed a yaml file, but I get all comments from sonar into the PR since the last version.
Greetings,
Harry
yeah, would be great if it just reviewed the changes from azure devops