Invalid new code period. ‘2021-01-01’ is not one of: integer > 0, date before current analysis j, “previous_version”, or version string that exists in the project’ Please contact a project administrator to correct this setting
The answer @ganncamp provided within the thread below has solved my problem temporarily:
However, I was curious if it would it be possible to avoid the fail-fast approach?
The reason is:
My company would like to be able to track the “New Code” coverage metrics for ALL projects within our company starting at the beginning of each quarter.
I recently set the default/sonar-system-level “New Code Period” to 01/01/2021 about a week ago (this is when we decided that we wanted to begin monitoring quarterly new code metrics).
Unfortunately, there are many projects which have not had any analysis performed since before 01/01/2021; For these projects, when anyone tries to perform a new analysis against them they receive the error mentioned above.
When a project receives this error we are reactively adjusting it’s project-level “New Code Period” date to a date before the last successful analysis then running a new analysis and readjusting the project’s “New Code Period” back to 01-01-2021
As you can see, the next time we adjust the system-level “New Code Period” to the start of the new/next quarter (04/01/2021) then I suspect we will begin to see these errors appear more often.
Any ideas on how I could come up with a proper solution?
In my mind this is more a procedural than a technical question. And the answer I’m going to offer is probably not the one you want: analyze more often.
You “recently” (so… mid-February?) set the New Code Period to 1 January & had projects fail analysis because they hadn’t analyzed in the new year… That tells me that
the projects aren’t under active development
the projects aren’t being analyzed regularly
both
Best practice says that you should analyze after every commit for reasonably sized projects or at least once a day (on a timer) for projects actually being developed.
Seems I made the change around 4 PM PST on February 1st.
I see. Since this is true:
the projects aren’t under active development
Is there any suggestion/best-practice on how to go about handling these projects?
I thought some ideas may be…
Analyze these project more frequently (maybe a timer set to analyze at the beginning of the quarter then I adjust the code coverage period after a day or two after the start of the quarter)
Create an internal help doc. on how to fix the problem then provide it to the project managers so they could fix the problem when it arises.
Come up with a new plan that doesn’t involve tracking code coverage from a quarterly perspective.
Let’s back up to what you’re trying to accomplish. The projects aren’t under active development, so what would quarterly tracking accomplish? No development → no change → nothing to track…?
Unless there’s occasional / intermittent development on these projects (let’s say a bug fix every month or two) and you just need to make sure these mostly-stable projects aren’t inching in the wrong direction…?
In that case (and in most cases, in fact), best practice would be to analyze with every commit. and maybe set the New Code Period to previous_version (assuming you increment the version string you pass into SonarQube for each production release).
I see what you mean. Yes, it does help. Okay. I’ll work with this. Will focus on setting a new code period to the previous version with a quality gate to ensure that they’re not inching in the wrong direction whenever some work is performed against these (mostly) inactive projects.
