New sandboxing feature

SonarQube Server / Community Build
1

Dear Sonarsource team,

we have installed Enterprise Edition v2025.6.1 on our testserver.

I tested the new sandboxing feature because it sounds very interesting.

Now I have several questions/proposals:

  1. We often update our own Quality Profiles together with a Sonarqube update. How does the sandboxing feature behave in this situation? Does it also move issues caused by our QP update to the sandbox? Or which issues in detail are shown in the sandbox?
  2. Is it possible to also use the sandboxing feature if we do an update of our Quality Profiles independent from a Sonar update? This would be of very high value for us. Because if we do ruleset updates we also want to give the teams the opportunity to not be directly blocked by new issues and have some time to fix them before we might remove them from the sandbox again. For us this is the same usecase.
  3. I already noticed that on creation of new branches the sandboxing feature is not working. (If the first scan after an update creates a new branch - based on an already existing branch) This should be fixed from my point of view.
1 Like
2

Hi,

The sandbox is intended to isolate new issues raised after a server upgrade, both from new rules and from updated rules. So I suspect the algorithm won’t be smart enough to distinguish between new issues raised after upgrade from rules that were previously in the profile and new issues raised after upgrade from rules that just got moved into the profile. So if you get your timing right, I believe the issues from rules you add to your profile would be sandboxed as well. And this would be worth testing.

I’ll flag this for the PMs.

I think this scenario is beyond the expected scope of the feature.

 
Ann

4

Hi Ann, thank you for the feedback.

The sandbox is intended to isolate new issues raised after a server upgrade, both from new rules and from updated rules. So I suspect the algorithm won’t be smart enough to distinguish between new issues raised after upgrade from rules that were previously in the profile and new issues raised after upgrade from rules that just got moved into the profile. So if you get your timing right, I believe the issues from rules you add to your profile would be sandboxed as well. And this would be worth testing.

Unfortunately it does not work as you expected. I tested it again. If I enable additional rules or update the severity of rules, these changes are not put into the sandbox. And this makes the feature essentially useless for us. We would need to have all issues in the sandbox. Otherwise developers would still be blocked by the appearance of the new issues.

I think this scenario is beyond the expected scope of the feature.

I think it should not be beyond the scope and I will try to explain. We create a new branch for each iteration. So the situation might be the following in an example project:

The team is working on iteration 10. There is branch DEV-10. Now we have a Sonar update. Next scan on DEV-10 will put the issues into the sandbox. Next day we might start with iteration 11. The first scan for iteration 11 will create branch DEV-11, based on DEV-10. In this branch the issues are not in the sandbox anymore and we are directly blocked. This is no exotic edge case but how we are working every day, so we would need that to be able to use the sandboxing feature at all. Otherwise it would just confuse everyone, if different branches handle the issues in a different way.

Regards, Wiebke

5

Hi,

Can you share your testing scenario? I would expect something like

  • edit profile*
  • perform upgrade
  • edit profile*
  • run first post-upgrade analysis → issues sandboxed

Note that issues are only sandboxed on the first analysis after an upgrade.

* Edit profile immediately before or immediately after the upgrade

As I said, I’ve flagged this thread for the PMs.

 
Ann

7

Hi,

my testing scenario was the following:

  1. perform upgrade from 2025.1 to 2025.6.1
  2. edit QP (added new rules as well as did changes in the severity of existing rules)
  3. run first post-upgrade analysis

→ Some issues are sandboxed but we also have new issues that are not sandboxed. Please see the secreenshots.

Regards, Wiebke

Screenshot 2026-01-22 082217
Screenshot 2026-01-22 082217616×935 70.2 KB

Screenshot 2026-01-22 082336
Screenshot 2026-01-22 0823361553×900 96.6 KB

8

Hi,

Thanks for sharing your scenario. Maybe the algo is smarter than I thought. :thinking: Could you try it in the other order?

 
Thx,
Ann

9

Hi Ann,

unfortunately I cannot do it the other way round easily. In my company I am just a normal user and have admin rights on the projects that belong to my area. I am no global Sonar admin. We have a team that runs the sonar servers and we have a prod server and a test server. These servers are used for the whole company.

On the testserver our admin team has now already done the update so I would have to ask them to either revert this or create a special additional server where we can try to test this scenario together. But this would be some effort. I will anyhow ask them if they see a possibility to support me in this topic.

Regards, Wiebke

1 Like
10

Hi Wiebke,

I understand. I appreciate what you’ve already done. As I said, this is flagged for the PMs. I’m sure they’ll be interested in your take.

 
Thx,
Ann

11

Hi again,

one more thing regarding the changed order:

Even if it would work if it is done in the other order, this would not help much, because we usually do our ruleset update based on new or updated rules from the sonar update. Of course we cannot update our ruleset to use new rules introduced by a sonar update before that update is done…

Regards, Wiebke

1 Like