Why cant Code Period start from my main branch when scanning a feature branch?

I am running Sonarqube 8.3 Developer edition

I was excited to get Developer edition and start running feature branch based scans. However, a strange thing I noticed was that if I had a failing Quality Gate all i would have to do to resolve this and have the QG pass would be to run the build again.

After some digging I think this is caused by the fact that every build we do has a new version number - this allows traceability of any artefact back to a particular build.

The Code Period just looks at the previous version (in our case, one build prior) when deciding on the QG and so now it passes.

I was expecting to be able to configure Code Period to be able to point to the last version from my master branch but it seems this is not possible.

Reading some topics on this forum i see some suggestions saying people have written some automation to set the Code Period to number of days since the last master scan but this seems clunky. Also, let’s say Code Period is set to 10 days as that’s when my master build was last released. How does SonarQube know to check master branch and not my 10 day old feature branch.

I feel like i’m really missing the mark on how this feature is supposed to work but i really don’t see how Code Period can ever be useful unless it’s referencing the main branch.

How would SonarQube expect this to work when I have a new version number every release? It seems it doesn’t.

In this post Fabrice Bellingard states

I have the feeling that one root of your difficulties come from how your teams are using the sonar.projectVersion property. This property is not meant to design a branch, a tag, or a specific commit. It is supposed to represent the “functional” version of your project (version that is supposed to be updated/changes according to your release cycle).

I think this is a mistake. In a world of CI where any build could produce a release candidate you can’t just arbitrarily choose a “functional version”. Version numbers change, a lot. That said, i could make changes to our pipeline to keep our feature branch version static (at the expense of the rest of our tooling) but does this guarantee that “Previous Version” always means the main branch previous version?

Hi,

The expectation is that if you have a different version number at each build, then this won’t work. For historical context, the previous_version method was created in a Maven-centric model, where you didn’t change the artifact’s version at every build. Given what you’re doing, you probably want to use the ‘Specific analysis’ setting. It’s set per-branch, so use the gear icon to get to it:

You’ll also be pleased to learn that with 8.4 you’ll be able to set a reference branch which other branches are compared to.

As a side note, if you can separate your version from your build string, you may be interested in the fact that you have the ability to pass a build string in to analysis. It’ll be stored with the analysis so you can tie QG status to the build and presumably back to the commit if you like.

 
HTH,
Ann

This is great news! I just have two questions:

  1. Will it be available on CE as well? :pray:
  2. Is there any chance this will ever become an analysis parameter (as previously requested) instead of only a project-wide setting? Typical use case:
    • I have a project with several long-lived branches
    • Devs primarily branch off of and merge back to these branches and rarely to the “main” project branch
    • We’d like SonarQube to always use the “PR target” branch as the reference for scans, but only the server-side configuration is used today. :disappointed:

Thanks for your clear response!

Hi,

Uhm… will the ability to set another branch as the reference for your branch be available on CE? …No. There aren’t branches in CE. (Why do I have the sense that I’m missing something here?)

No clue. Let’s wait until it’s released & go from there. :smile:

 
Ann

Thanks Ann that is a great help.

Do you have an expected release date (closest month) for 8.4?

Also, are there any plans for allowing the New Code setting to be configured using sonar.properties in the project rather than through the web interface? We’re all about the configuration as code here :slight_smile:

Sonarsoure Jira has 29/Jun/20 as internal release date for Sonarqube 8.4
The official release is usually some days later, so i guess it will come mid-July

1 Like

Hi,

Gilbert’s right about the target release date. Unfortunately he’s also right that somehow release usually slips a couple days. But mid-July is a bit much! :stuck_out_tongue_winking_eye:. Look for it in the week of the 29th.

Regarding setting the New Code period via analysis parameters, no, there are no plans.

 
Ann

Uhm… will the ability to set another branch as the reference for your branch be available on CE? …No. There aren’t branches in CE. (Why do I have the sense that I’m missing something here?)

Oops, sorry for the confusion—I’m aware branches aren’t supported in CE, but in our setup (still on 7.9 LTS), we use the branch name as the sonar.projectVersion for our scans. I was hoping this new feature might fill the gap created by the removal of the ability to set an arbitrary version label as new code period, but it looks like it’s irrelevant for us.

I’m still rooting for a later 8.x to restore this removed feature, as in 7.x and earlier:

Thanks for your answers anyway, @ganncamp!

Hi Anne,

I just started using 8.4 today and can see the new Code Period feature for setting against my master branch. Excellent!

Can you point me to towards the API endpoint I need to call to so I can programatically update this for all of my projects?

Thanks,

Hi,

The easiest thing to do here is make the call via your browser & use the developer tools to eavesdrop to see which services are called.

 
HTH,
Ann

That is bad news for our team here.

  • There is one more aspect to configure in the UI when creating a new project
  • We are using multiple “develop” branches like “develop/variantX” as there is parallel development of similar variants of the product. Therefore sonar.branch.target was simply set (in the Jenkinsfile) to the respective development branch so when branching from it the correct target branch is automatically given. Now with the “reference branch” setting i would have to configure the respective develop branch for every new feature branch in the UI.

I have the feeling that this goes 360°: first there is the concept of new code relative to the target branch and the only feature missing was that all issues can be shown also for branches so its more efficient if you want to fix a lot of issues at once. Then the branch analysis concept has been changed and the “target branch” feature has been dropped. With 8.4 it is back as “reference branch” that needs to be configured manually …

g,
Peter

1 Like

For folks who want to have a say in how the New Code Period concept evolves, an official (short) survey has been posted here:

(I’m of course choosing “Other” and adding all my thoughts…)

The survey closes pretty soon (in about a week), so please take a couple minutes to respond now if you’re still interested in this topic—thanks!

1 Like