Server cache not found when target branch of a PR isn't the main one

SonarQube Cloud
1

Hi.

We run SonarCloud C++ analysis relying on the server cache. It works fine when a pull request #1 from branch-1 is opened toward master, but not when another pull request #2 is opened from branch-2 toward branch-1 (which happens quite often with “stacked PR” workflow).

According to the documentation:

The cached analysis results speed up subsequent analyses by analyzing the only things that have changed between the two analyses.

  • For branch analysis, an analysis cache is stored on the server per branch.
  • For pull request analysis, the cache of the base branch is used and not persisted.
  • If no cache is found, the cache of the Main branch is used.

As such, I’m expecting the pull request #2 to use the cache from the main branch as a fallback. However, this is not what happen. The entire project is analyzed again, because the cache was not found.

Here is an extract from the logs of pull request #2:

INFO: Load branch configuration
INFO: Detected analysis for pull request '2' targeting 'branch-1'
INFO: Auto-configuring pull request 2
INFO: The base branch 'branch-1' is only analyzed as a pull request. Using its base instead: 'master'
INFO: Load branch configuration (done) | time=368ms
[...]
INFO: Found empty cache on server
INFO: [pool-6-thread-1] /opt/atlassian/pipelines/agent/build/project/main.cpp

In comparison, a pull request opened directly toward master works fine:

INFO: Load branch configuration
INFO: Detected analysis for pull request '1' targeting 'master'
INFO: Auto-configuring pull request 1
INFO: Load branch configuration (done) | time=285ms
[...]
INFO: Loading cache from: server
INFO: Cache hit for: /opt/atlassian/pipelines/agent/build/project/main.cpp

Please, could someone explain why pull requests directed toward short-lived branches aren’t using the cache from master as a fallback?

Attachments:

5

Hi @ADGB

Welcome to the community! :slight_smile:

I need some time to investigate this behaviour and to clarify the ‘why’. I’ll come back to you once I know more.

Anita

1 Like
11

Hi there.

Is there anything I can do on my side to help investigate the issue?

I’m still facing this curious behavior with stacked PR. This causes the analysis to last for more than 1 hour instead of 5 min with the cache. Our Bitbucket pipelines are piling up and finally failing due to a lack of available resources.

12

Hi @ADGB

I’m really sorry for the delay, and your issue wasn’t forgotten :slight_smile:

It’s a bug, I was able to reproduce the problem and created an internal ticket to fix it.
As it impacts you a lot, we’ll prioritize the fix, however, I can’t promise any date when it will be tackled.

Anita

1 Like
14

Great, glad you were able to reproduce it and thanks for the update!

15

Hi @ADGB

The fix was just deployed, could you test to see whether it solves your problem?

Anita

16

@anita.stanisz I can confirm that the cache from the main branch is now used as fallback, and the analysis is much faster:

INFO: Load branch configuration
INFO: Detected analysis for pull request '2' targeting 'branch-1'
INFO: Auto-configuring pull request 2
INFO: The base branch 'branch-1' is only analyzed as a pull request. Using its base instead: 'master'
INFO: Load branch configuration (done) | time=584ms
[...]
INFO: Loading cache from: server
INFO: Cache hit for: /opt/atlassian/pipelines/agent/build/project/main.cpp

Thank you very much! :+1:

3 Likes
20

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.