Sonar report failing analysis in bitbucket pipeline

Hi i am using bitbucket cloud’s pipeline to trigger sonar whenever a commit is made on the repo.
My sonarversion is: 3.3.0.1492. My pipeline is analyzing multiple sub repo’s with their own respective projects on sonarcloud website. So I am running the sonar command in the pipeline many times. The problem is that some times the pipeline runs fine and sometimes it fails on a certain repo and is failing on a different repo everytime.

Ex:
bitbucket-pipeline:
run sonar on repo1
run sonar on repo2


run sonar on repo N

The pipeline would fail in one of the repo’s and never the same one. It would give me this error.

The error i get is:
`ERROR: Error parsing the report /opt/atlassian/pipelines/agent/build/repo1/vendor/…/…

ERROR: Caused by: java.io.FileNotFoundException: opt/atlassian/pipelines/agent/build/repo1/vendor/../...(Is a directory)

ERROR: Caused by: opt/atlassian/pipelines/agent/build/repo1/vendor/../...(Is a directory)

I’ve excluded the vendor’s path in sonar-project.properties. In some runs of sonar on a repo this error will not happen and some will. I am confused as to why this happens and how to solve it.

Hi @wyu19 and welcome to the community !

How did you set the exclusions ? Is vendor directory part of your codebase ?

Mickaël

1 Like

Hi Mickaël, I have set my exlcusions like this

sonar.sources=/opt/atlassian/pipelines/agent/build/repo
sonar.exclusions=**/reports/*.xml, **/vendor/**, portunus/vendor/

Each repo has their own sonar-project.properties with this exclusion
Vendor is part of our codebase.

Hi @wyu19,

Exclusions should target files, not only directories, so i suggest to change the

**/vendor/** 

To something like :

**/vendor/**/*.*

To target a wider depth of directories, and files inside them.

Please let me know.
Thanks.
Mickaël

Hi Mickaël,
I have tried to setting the exclusions to your recommendation.
The error seems to be that sonarqube is trying to analyze the repo too far deep.

This is the extent of our repo path:
/vesta/vendor/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/

But sonarqube is trying to analyze seems to be:

vesta/vendor/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/gopath/src/bitbucket.org/company/ota-dev/vesta-api/bin

which causes ‘java.io.FileNotFoundException:’.

Note: One of our folder name is called ‘bitbucket.org/company/ota-dev’, would this be the issue causing it to continuously look?

That could be a corner case of our regex parser, i will open a ticket on our side and let you know.

Thanks !

Hi Mickaël, have you received any updates on this issue?

Hi, We figured out the issue was because of a sym link in our repo causing sonar to recursively look for it.

2 Likes