We’re seeing severe degradation in our Bitbucket Cloud pipelines for a multi-module Maven project using Java.
Our last known good build time was Feb 2nd, which took 5m 41s to do our build with analysis included. The sensor reported javabugs [dbd] (done) | time=100340ms
Our first known bad build time was Feb 6th, which took 1h 34m 46s to do the same build.
Our command and pipeline didn’t change. We build it via mvn -B clean install org.sonarsource.scanner.maven:sonar-maven-plugin:sonar
Each subsequent build has been 1.5+ hours long, and a few have been killed at the 2 hour mark automatically.
Extracts from good
[INFO] --- sonar:3.9.1.2184:sonar (default-cli) @ com.respsys.rspf.root ---
[INFO] Bitbucket Cloud Pipelines detected, no host variable set. Defaulting to sonarcloud.io.
[INFO] User cache: /root/.sonar/cache
[INFO] SonarQube version: 8.0.0.52363
[INFO] Sensor javabugs [dbd]
[INFO] Reading IR files from: /opt/atlassian/pipelines/agent/build/com.respsys.rspf/target/sonar/ir/java
[INFO] Analyzing 4772 functions to detect bugs.
[INFO] Sensor javabugs [dbd] (done) | time=100340ms
[INFO] CPD Executor 14 files had no CPD blocks
[INFO] CPD Executor Calculating CPD for 218 files
[INFO] CPD Executor CPD calculation finished (done) | time=145ms
[INFO] Analysis report generated in 203ms, dir size=8 MB
[INFO] Analysis report compressed in 885ms, zip size=2 MB
[INFO] Analysis report uploaded in 485ms
[INFO] ANALYSIS SUCCESSFUL, you can find the results at:
[INFO] Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
[INFO] More about the report processing at
[INFO] Sensor cache published successfully
[INFO] Analysis total time: 4:24.046 s
The equivalent bad pipeline only a few days later:
[INFO] --- sonar:3.9.1.2184:sonar (default-cli) @ com.respsys.rspf.root ---
[INFO] Bitbucket Cloud Pipelines detected, no host variable set. Defaulting to sonarcloud.io.
[INFO] User cache: /root/.sonar/cache
[INFO] SonarQube version: 8.0.0.52496
[INFO] Sensor javabugs [dbd]
[INFO] Reading IR files from: /opt/atlassian/pipelines/agent/build/com.respsys.rspf/target/sonar/ir/java
[INFO] Analyzing 4772 functions to detect bugs.
[INFO] Sensor javabugs [dbd] (done) | time=5467358ms
[INFO] CPD Executor 14 files had no CPD blocks
[INFO] CPD Executor Calculating CPD for 218 files
[INFO] CPD Executor CPD calculation finished (done) | time=161ms
[INFO] Analysis report generated in 279ms, dir size=8 MB
[INFO] Analysis report compressed in 1112ms, zip size=2 MB
[INFO] Analysis report uploaded in 1651ms
[INFO] ANALYSIS SUCCESSFUL, you can find the results at:
[INFO] Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
[INFO] More about the report processing at
[INFO] Sensor cache published successfully
[INFO] Analysis total time: 1:33:26.250 s
Would you mind enabling debug logging, which I believe you can do by adding -X to the mvn command, and posting the full log, starting from the command, here?
What I do see is that around line 171077, there’s an approximately 1.5h gap:
20:27:45,849 [DEBUG] 20:27:45.849 435997495 paths have been skipped in function wsgdatamodel.MyWSGInterface#cloneMappings(Lwsgdatamodel/MyWSGInterface;Lmodel/RspfObjectList;)Lmodel/RspfObjectList;.
20:27:45,849 [DEBUG] 20:27:45.849 31 summary entries were discarded because the function summary for wsgdatamodel.MyWSGInterface#cloneMappings(Lwsgdatamodel/MyWSGInterface;Lmodel/RspfObjectList;)Lmodel/RspfObjectList; has exceeded the maximum number of function results.
22:06:01,046 [DEBUG] 22:06:01.046 Aborting analysis of wsgdatamodel.MyWSGInterface#<init>(Lwsgdatamodel/MyWSGInterface;Lwsgdatamodel/ActDiag;)V early because the maximum of 16000 analysed instructions has been reached.
22:06:01,050 [DEBUG] 22:06:01.050 Issue B at /opt/atlassian/pipelines/agent/build/AGFrameWork/src/main/java/wsgdatamodel/MyWSGInterface.java(1611:6 - 1611:27) suppressed by unknown constraint
Are you sure there’s no external suspension going on here? Because I’ve never seen analysis not log anything for more than… oh, a minute or so.
The only thing I removed from the log was the information prior to the invocation of the mvn command - otherwise, that is as complete as I can get from Bitbucket Cloud.
We have had some pipelines killed because they take 2+ hours, which exceeds the limit of Bitbucket’s pipelines. But this one wasn’t killed, and looking at the associated PR (which is how this was raised, to add the -e -X), SonarCloud is returning a positive analysis and displaying the badges. The sonarcloud.io page is showing that it has received the submission and it has passed.
But we’re not doing anything to suspend or delay it. We’re getting charged billing minutes, so we’re not going to be wanting to delay it and blow it out on our end.
We haven’t changed the image we build off or our build steps either.