Wrong ruleset applying

SonarCloud
1
  • ALM used: Bitbucket Cloud
  • CI system used: Circle CI
  • Scanner command used:
mvn --settings <settings-file-redacted> -B sonar:sonar \
    -Dsonar.login=<sonar-token-redacted> \
    -Dsonar.pullrequest.key=${CIRCLE_PULL_REQUEST##*/} \
    -Dsonar.pullrequest.branch=$CIRCLE_BRANCH \
    -Dsonar.pullrequest.base=master \
    -Dsonar.inclusions="$(git diff origin/master --name-only | xargs)" \
    -Dsonar.pullrequest.bitbucketcloud.repository=<repo-slug-redacted> \
    -Dsonar.pullrequest.bitbucketcloud.owner=<owner-slug-redacted>
  • Languages of the repository: Java

We have our own ruleset that extends the sonar way and has a few rules deactivated or modified. These rules seem to apply correctly to a full sonar scan against master which we run in one CI pipeline on a regular basis.

However, our PR pipelines don’t seem to be applying the same ruleset. Despite deliberately crafting a PR with changes aimed at triggering specific rule, none of them seem to trigger and only some very high level generic code smells (e.g. java:S2699: Add at least one assertion to this test case.) seem to be appearing.

The right ruleset appears in the sonar scan (there is a log line "Quality profile for java: ) and the increment of files in the PR scan report appears correct. It’s just the detection that seems wrong.

The only evidence I can find of something being wrong is the reporting processing link from the sonar scan, which has the contents:

{"errors":[{"msg":"Project doesn\u0027t exist"}]}

However, our successful master branch runs have the exact same contents in their link and seem to be working so I suspect this is a red herring.

2

Can you share an example (alongside code) of a rule that isn’t being triggered?

3

Hi Colin,

Thanks for reaching out, turns out we had two compounding issues: one of our tokens was misconfigured and then some of the rules we expected to see were in test classes.

The only two things that really stood out from trying to debug this mess is two-fold: firstly, it’s really unclear when a scan doesn’t have the right token, the error messages don’t telegraph it very well at all. It’d be nice for the client to be clearer about these sorts of issues.

The second is that it is unfortunate that you have to run the whole scan before you can verify the connection is correct. I wonder if some kind of “test-connection” step could be added to the maven plugin that can be bound to an earlier lifecycle step and allow the client to fail-fast?

4

Thanks for the feedback @danikov_matillion – I’ll flag it for attention!

1 Like