Today, the only way to define a leak period is through the server UI, and this extra configuration step can become tedious when all of our workflows are completely configured as code, and we have many teams using some aspects of SonarQube slightly differently from each other.
To make this oftenmisunderstood feature more easily configurable, I’d like to request that the leak period be definable on a per-scan basis.
I do acknowledge some workarounds that avoid interacting with the server UI are available, e.g. setting the project’s leak period via an API call, but this is not something I’d like to encourage.
Please let me know if this improvement can be put under consideration. Thanks!
One team scans their projects with the sonar.projectVersion always set to the branch name (or tag, or commit hash, etc.) and wants a project’s leak period to always be relative to a specific version which changes relative to the project’s release cycle. Existing tooling would make it easy to determine the desired target leak period and set if it could be specified as a scan parameter, but today the only way to do this is frequent updates via the server UI.
Similarly, one team wants their project’s leak period to change based on the date of the last release.
Developers working on different parts of the same complex feature each create a new branch based off the “main” feature branch. In this team’s workflow, the sonar.projectVersion is always the commit hash, and all scans of such branches should have a leak period based off the commit hash of the parent branch’s current tip.
I could list more examples, but the common pattern here is that the leak period is a moving target in these and many other pretty common cases. Setting a project-wide leak period that can’t be overridden per-analysis is often incompatible with these cases. (Even if it was compatible, changing so often it via the UI isn’t feasible, especially when not all users can have access to the project’s administrative UI.)
All that said, it would make sense to make this parametrizable on a scan-by-scan basis.
…and it makes me very nervous. After reading the description and skimming some of the linked issues, it’s become apparent that the existing leak period setting will be replaced by something more restrictive, removing the ability for users to set the new code baseline to a specific version or date and instead requiring us to set it to a specific analysis ID.
If I understand correctly, this will make many of my teams’ main use cases of the “New Code Period” impossible to satisfy (even if this new setting were configurable as a scan parameter) since we most often want to target a “version” without needing to be aware of the analysis ID that corresponds to the last scan of that version.
Does the SonarQube team consider ours as invalid/irrelevant use cases? Are there cleaner alternatives? Am I just misunderstanding the issue description? I’m not sure, but perhaps this is a conversation for a new topic. (Update: Topic posted here.)
In any case, to hopefully get back on-topic, I still stand by my original request of making the “new code period baseline” (or whatever it will be called) an analysis parameter.
Hi @usmonster, 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).
For instance, when you talk about feature branches created from another branch, if sonar.projectVersion is set to the version currently being developed, it should not change during the lifetime of this branch, and therefore the leak will automatically be the whole period started when you performed the first analysis of that branch.
By the way, what environment is your team working with? (for instance, Git with a solution like Bitbucket Server or Azure DevOps Server) Are you using pull requests?
In most web- or service-based projects, there is no such concept of “release version” apart from the commit hash, or the date, or the branch. Most of our projects have several releases per day, and our primary goal in using SonarQube is to make sure the code in new branches and pull requests won’t leak any quality regressions into our main/stable/release branches. I’d argue that this is an extremely common use case, and the current version of SonarQube—even Community Edition, which we use—does a pretty good job of handling it by allowing users to adapt the loose notion of projectVersion (more akin to a “scan label” as I mentioned earlier) to their own workflows. (Upcoming changes might remove this advantage, but that’s already another topic.)
We’re using Bitbucket Server and launching SonarQube analyses as part of our Jenkins pipelines. All our projects’ repos include Jenkinsfiles that define their pipelines, and we maximally avoid configuring any CI/CD workflows from the Jenkins UI or other interfaces—we want to keep the configuration as code. As such, we’d also like to avoid using the SonarQube Administration UI to configure per-project settings by keeping analysis configuration in sonar-project.properties or in gradle scripts, etc.
Regardless of how we’re using projectVersion (I’d like to keep it to the other topic), I believe my request of having the New Code Period definable or overridable as a scan parameter would greatly simplify our workflow for this rather common situation.
There haven’t been any updates to this. We have a lot of concerns about how Leak Period is being used in 8.x. We specify our version for any build as 1.Jenkins-Job-#.commit-hash. This is used throughout our CI/CD system to enable us to tie all our scans (Checkmarx, Nexus IQ and Sonarqube) to a specific build as well as provide traceability from SCM through to the deployed binaries. Developers have always designated this version as deployed to Production as their New Code Period.
In our mainframe COBOL instance we use the date the module was last deployed to Production. We can’t use versions because our COBOL developers have never used versioning in Panvalet and have no way to track versions.
If you’re breaking this model it’s going to be a massive process change for us.
I have a version on my application but the measures are done monthly so I need to set sonar.leak.period to the last month day. I have to change manually more than 50 projects than I did a Jenkins job to change the date automatically setting this parameter on sonar scanner. What a surprise that it’s not working because sonar scanner don’t support this.
Please this is really needed for me. I don’t have others to help me change this parameter manually every month on my enterprise and each month we have more projects analysed by sonar.
Did either of you come up with an alternative solution to that? (apart from changing the parameter each time manually).
How do you manage leak periods based on your sonar experience (to set new code period)?
We’re going to go with the new model for our mid-tier (Java, .Net, JS) builds.
Our COBOL system is much different. I may need to set up some scripting where we determine the date that project was last deployed to Production and set the new code period to the newest version prior to the production date. Annoying but not impossible.
The new model for the new code period doesn’t allow specifying a date. You have to select a specific analysis. We’ll have to script to select the first analysis prior to the production deployment date.
Having a UI to change the leak period is nice to play around with (https://jira.sonarsource.com/browse/MMF-1994) but having that as a analysis parameter opens the door to automation at scale and could possibly fix the issue some have with the new 8.x branching model (e.g. having a dedicated baseline before the first analysis).
