Project level new code setting won't save

[thefang12]

Describe the bug
Setting new_code_period at the project level doesn't work at all.
To Reproduce
Steps to reproduce the behavior:

1. create a project
2. go to Project Settings > New Code
3. set the Define a specific setting for this project setting to any other than global default
4. click save
5. UI will show saved but reloading the page shows the project new_code_period doesn't change

Expected behavior
Project new_code_period is persisted once changed from the global default.

Screenshots
If applicable, add screenshots to help explain your problem.
Setting new_code_period:

After reload:

Software Versions

• SonarQube Versions: 8.4.1, 8.4.0,8.4.2
• Plugin Version: 1.5.0

Additional Comments
The feature works correctly at global and branch levels.
Tried setting it using the UI and the web API and both return a 200 without persisitiing the new_code_period change. The only workaround I've found is to insert the new_code_period record in the new_code_periods table manually 😞 .

[anand-ispg]

@thefang12 I also had this issue but If you notice while making changes, it says this setting will apply after your next scan. So after making the change and running another analysis it worked.

[powerdefy]

I also have the issue.

[thefang12]

@anand-ispg when you change the setting in the UI it retroactively changes any branch that has already been scanned to the new_code_period that why it works on next scan, the issue is for any new branches it still uses the global new_code_period not the one set at a project level.
@powerdefy it's not a nice workaround, but the only thing that got this working was to manually access the DB and insert a new_code_period record with the project uuid and branch name column null in the new_code_periods table. Hope it helps.

[powerdefy]

@thefang12 Thank you, I insert a new row manually and it works.

[Dr-Dream]

@thefang12. Thanks for workaround.
Same for me.
When setting reference branch for project it fills new_code_period.branch_uuid with project_uuid.
UI shows this setting as for master branch.
if update branch_uuid null it works.
After update you should update master branch settings at branch level.

[mc1arke]

@Dr-Dream can you confirm the exact steps your taking here? I presume this is updates to values in the database you're making, so it would be useful to know which tables and columns you're altering, and example of their pre and post change values are

[Dr-Dream]

@mc1arke ,

As it works for me.

As i understood, according to what i saw during changes in new_code_periods through UI - project_uuid and branch_uuid have same value.

So when you change project settings from default in UI - new record in new_code_periods record filled project_uuid and branch_uuid with same uuid value.

So if branch_uuid is set, setting reffers to master branch only.

Actually, currently, there is no way to change this settings at project level through UI.
Branch-level settings only.

If barnch_uuid is null, it counted as project settings.
i discovered it updating record for master branch, by 'update new_code_periods set branch_uuid=null where .....' directly in postgres.

After that, i've changed through UI settings exactly for master branch, because it should differs from project one (should not reffer itself).

After that all new analisys for new branches done against master.

I hope it will helps.

One more note. There is no unique constraints on table, so accidentally you could make two or more settings at project level. That will be followed by errors and you'll be not able to get project level settings of new code in UI at all.
Experienced myself.

[Dr-Dream]

Exact steps to reproduce and fix for 1 project, not a simpliest one. :)
For multiple projects at once i don't have solution..

1. Newly created project

Selecting new_code periods by project_uuid.

sonarDB=> 
select * from new_code_periods where project_uuid='AXYKmHx31W5kG7yc_CXo';
uuid | project_uuid | branch_uuid | type | value | updated_at | created_at
------+--------------+-------------+------+-------+------------+------------
(0 rows)

2. Changing default settings.
   

sonarDB=> select * from new_code_periods where project_uuid='AXYKmHx31W5kG7yc_CXo';
         uuid         |     project_uuid     |     branch_uuid      |       type       | value  |  updated_at   |  created_at
----------------------+----------------------+----------------------+------------------+--------+---------------+---------------
 AXYKtQCv1W5kG7yc_CX1 | AXYKmHx31W5kG7yc_CXo | AXYKmHx31W5kG7yc_CXo | REFERENCE_BRANCH | master | 1606497403052 | 1606497403052
(1 row)

3. Refresh
   

sonarDB=> select * from new_code_periods where project_uuid='AXYKmHx31W5kG7yc_CXo';
         uuid         |     project_uuid     |     branch_uuid      |       type       | value  |  updated_at   |  created_at
----------------------+----------------------+----------------------+------------------+--------+---------------+---------------
 AXYKtQCv1W5kG7yc_CX1 | AXYKmHx31W5kG7yc_CXo | AXYKmHx31W5kG7yc_CXo | REFERENCE_BRANCH | master | 1606497403052 | 1606497403052
(1 row)

4. Update & Refresh

sonarDB=> update new_code_periods set branch_uuid=null where uuid='AXYKtQCv1W5kG7yc_CX1';
UPDATE 1

sonarDB=> select * from new_code_periods where project_uuid='AXYKmHx31W5kG7yc_CXo';
         uuid         |     project_uuid     |     branch_uuid      |       type       | value  |  updated_at   |  created_at
----------------------+----------------------+----------------------+------------------+--------+---------------+---------------
 AXYKtQCv1W5kG7yc_CX1 | AXYKmHx31W5kG7yc_CXo |                      | REFERENCE_BRANCH | master | 1606497403052 | 1606497403052
(1 row)

5. Saved master branch settings at branch level & refresh
   

sonarDB=> select * from new_code_periods where project_uuid='AXYKmHx31W5kG7yc_CXo';
         uuid         |     project_uuid     |     branch_uuid      |       type       | value  |  updated_at   |  created_at
----------------------+----------------------+----------------------+------------------+--------+---------------+---------------
 AXYKtQCv1W5kG7yc_CX1 | AXYKmHx31W5kG7yc_CXo |                      | REFERENCE_BRANCH | master | 1606497403052 | 1606497403052
 AXYKwcip1W5kG7yc_CX2 | AXYKmHx31W5kG7yc_CXo | AXYKmHx31W5kG7yc_CXo | PREVIOUS_VERSION |        | 1606498240679 | 1606498240679
(2 rows)

[Sleepy-GH]

I'm running into this as well with the new SonarQube 8.9 LTS version and 1.8.0 version of the plugin.

[BlankSergey]

when it will be released?

[pro-krastinator]

Looking forward to release as well :)

[Golovanoff]

It's a miracle we need - the miracle
😀

[mc1arke]

Released in v1.9.0 of the plugin.

[Sleepy-GH]

@mc1arke Any chance that this can get backported to version 1.8.0 of the plugin?

[mc1arke]

@mc1arke Any chance that this can get backported to version 1.8.0 of the plugin?

Yes! I was giving it a couple of days between the 1.9.0 release and performing any back-porting to make sure no-one reported any major issues. I'll be looking to back-port all the 1.9.0 functional changes other than the commit for supporting Sonarqube 9.0. I'll hopefully get a 1.8.1 release of the plugin out toward the end of this week.

[Sleepy-GH]

Yes! I was giving it a couple of days between the 1.9.0 release and performing any back-porting to make sure no-one reported any major issues. I'll be looking to back-port all the 1.9.0 functional changes other than the commit for supporting Sonarqube 9.0. I'll hopefully get a 1.8.1 release of the plugin out toward the end of this week.

This is awesome. Thanks for your effort, it's much appreciated!

[mc1arke]

Backported to 1.8.1 of the plugin for Sonarqube 8.9 support.