In theory, if we back-dated the new code definition to 5 years ago in an existing project, will that automatically declare everything that was created within the last 5 years as “new code?” We are assuming that is how it works, but we wanted to confirm.
Reading your question I’ve a feeling that you might want to use something else more suited than the new code definition for what you are trying to achieve.
So before answering your question I’d like to have a bit of clarification and to know why you are trying to figure that out ?
What are you trying to achieve ? And what’s your use case ?
So the development managers like the clean-as-you-code policy. The question in addition to that was, how can they ensure that all “old” code is also scanned so they can address/prioritize existing issues?
So wherever you have a new code period or not, or if it’s short or long doesn’t change the fact that all your code (old code too) is scanned. The new code period is just a way of working to help fix your project quality by focusing mainly on the new code that is added by the developers.
And our default Quality Gate is ensuring this by setting some conditions mainly on the new code.
But you can easily change it to also have conditions on all the code (old code too), if you want to make sure you don’t go over some threshold on your overall projects.
I think you should keep a reasonable definition of what you consider new code (if you are versioning your project or doing some kind of release, usually a good definition of new code is everything added since the last version/release, so that you are sure your next one is clean and you didn’t introduce new issues). And adjust the Quality Gate that you use to add some conditions on the overall code so that you keep the old code in check too.
Ok, thanks. So to put a bow on it, the results of a scan (Vulnerabilities, Hotfixes, code smells, etc.) are reflective of the entire code base in the repos regardless of the new code definition?
Yes exactly, except for pull requests, in a pull request you will see only the issues added on the code that has been added in the pull request.
But when looking at your main branch, you will see both the issues on old code and on new code. For example on that screenshot, you can see on top of the yellow background the issues for the new code (which is a 30 days new code period in this case). And on the left, on top of the white/blue background, are the issues on the overall code (old and new):
And here you can see that the quality gate is passing (green) even though there is an E rating on the security hotspots on the overall code, and this is because our default quality gate conditions are based only on the new code, but you could customize it.