Steps to reproduce
Using bitbucket piplines, run the pipeline as normal. The tests will pass, but on the sonarcloud website it will say “The “release-developer” branch has no lines of code.”
Potential workaround
None.
This has been working perfectly for 4 months now, but today it suddenly broke. All the keys and properties are the same and there has been no updates, on my end at least. The only weird thing i have noticed is that in the logs it will say “INFO: 0 files indexed”, and on the website it will say “The “release-developer” branch has no lines of code.”
I checked a previous working pipeline on a branch which has no new code which said “INFO: 15 files indexed”. I ran this branch again and it now says “0 files” and will get the same result as mentioned.
I am also using the free subscription with a public repository. Sonarcloud will recognize the different analyzed branches as usual.
We had been analyzing our code automatically with bitbucket and we had been seeing the results on the board, however, a few days ago we began to see the message “The main branch has no lines of code”, the latest changes we made were: we changed the default branch from master to develop, we created a new Quality Gate and we excluded the test project using the tag true.
BUT if we run the same commands from our local machine (manually) results show up on the board
ALM used: Bitbucket Cloud
CI system used: Bitbucket Cloud
Languages of the repository: .Net Core 3.1
Scanner command:
dotnet sonarscanner begin /k:“project key” /d:“sonar.login=123” /v:“bitbucket version” /o:organization key" /d:“sonar.host.url=https://sonarcloud.io” /d:sonar.cs.opencover.reportsPaths=“coverage.opencover.xml”
dotnet build
dotnet sonarscanner end /d:“sonar.login=123”
Attached you can find three logs OldBitbucketLog-WithResults.txt (This is the log we got when we ran the analysis automatically using bitbucket pipeline a few days ago and at that moment we could see results) BitbucketLog-NoResults.txt (This is the log we got yesterday when running the analysis automatically using bitbucket pipeline and results are not loaded on the board) LocalAnalysisLog.txt (This is the log we get when running the analysis manually from the local machine and results are loaded to the board)
When I compare the logs (local and bitbucket) I noticed that the following lines do not exist in the log BitbucketLog-NoResults.txt: INFO: Quality profile for cs: CM Profile INFO: Sensor C# [csharp] INFO: SCM Publisher SCM provider for this project is: git INFO: SCM Publisher 75 source files to be analyzed INFO: SCM Publisher 75/75 source files have been analyzed (done) | time=646ms
And the following lines show 0 files
INFO: CPD Executor Calculating CPD for 0 files
INFO: CPD Executor CPD calculation finished (done) | time=0ms
We’ve been using SonarCloud for a while analyzing Java and JavaScript projects. The repositories are on BitBucket and the builds are done via BitBucket pipelines.
Things were working fine with SonarCloud showing results across branches. However these projects have suddenly started showing “The main branch has no lines of code” from the last few builds.
We’ve tries changing main branches and recreating projects on SonarCloud but ends up with the same issue.
Same issue, I opened a topic too: Java project wrong trying Javascript/Typescript analysis
My problem seems to be the scanner ignoring java files because of javascript exclusion filter, even that my repository do not have any javascript file.
same issue. Both of my typescript and Java projects stop working.
It seems something wrong with Bitbucket and Sonar as if I run the analysis locally from the command line it is totally fine, with the latest sonar scan maven plugin. However, even I put in exactly same command I used locally, it still generats no result from bitbucket pipeline.
Same issue here. I am working on a javascript project that was running fine in a bitbucket pipeline before:
- pipe: sonarsource/sonarcloud-scan:1.2.2
Everything seems to work fine during the pipeline execution, except for these INFO messages:
INFO: Indexing files…
INFO: Project configuration:
INFO:
INFO: 0 files indexed
The analysis run by sonar-scanner no longer finds any files to analyze in Travis projects.
See for example this build. It has been run using the sonar-scanner -X option to enable full debugging info.
Scroll down to line 994 and following of the build log. You will see lines like this:
14:05:44.136 DEBUG: File Core/src/package-info.java was excluded by sonar.javascript.exclusions or sonar.typescript.exclusions
14:05:44.136 DEBUG: 'Core/src/package-info.java' excluded by org.sonar.plugins.javascript.JavaScriptExclusionsFileFilter
It turns out that all the Java source files in the project are excluded by this JavaScriptExclusionsFileFilter. A bug report has been filed on Travis, and the Travis staff discovered that the issue lies in the pattern used by this filter, which discards any file inside a folder called build:
As a result, the filter discards all the files in a Travis build. Quoting Travis’ staff:
This is a bug (oversight) in the pattern matching behavior in my book. These patterns are meant to be matched against the part of the path under the project root rather than absolute path.
Workaround
Adding these two lines in sonar-project.properties :
I am using SonarCloud and Bitbucket Cloud Pipelines the project was working fine until 2021-04-30, and for some reason, the scanner stop indexing java files and do not analyze any file.
Enable debug log and found this for all my java files:
[DEBUG] 13:46:30.773 File src/main/java/example.java was excluded by sonar.javascript.exclusions or sonar.typescript.exclusions
Found a previous logs that says the javascript analysis is enable, but I do not have any javascript file, this log was present on the successful execution too.
[INFO] 13:46:25.859 JavaScript/TypeScript frontend is enabled
I’ve merged all these threads into one – I hope you don’t mind (I really don’t want to be posting the same answer on 5 topics).
Thank you for the reports. The right team has been notiffied. Kudos to @sylvainhalle for an excellent summary of the issue (and finding what is most likely the root cause).
The workaround he mentions should indeed address the issue temporarily.
When there is a further update on this, we will come back on this thread.