How do we know the date when an issue was first found by an analysis?
We use SonarQube Community Edition 8.7.1.
We need to know the date when an issue was first found by an analysis. At our company, our software developers must follow internal security policies and compliance requirements. One of the requirements is to not exceed the grace period of an issue. The grace period is calculated using the date when an analysis first found the issue, and the severity of the issue, for example 30 days for blocker issues, and 90 days for minor issues. The problem is we do not know when an issue was first found.
We tried to use the field creationDate returned by GET api/issues/search . But according to the Issues documentation, it seems that is the date when the source code was added to the repository, not when the issue was found.
Because of backdating, there’s not a good way to do what you’re after. On the other hand, we really believe that the Clean as You Code approach is really the way to go. At the same time, I understand your desire to clean up old Blockers. I suggest an initial period after the first analysis where you identify the must-fix issues on old code and get them cleaned up. And after that, Clean as You Code should do what you need.
Thanks for the response. We also believe in Clean as You Code, and our most modern projects are already achieving this.
But we also have legacy projects in the order of 1Gloc with check-in dates as old as ~2000. It will take them a long time to reach Clean as You Code.
Our goal is to eventually purchase SonarQube Enterprise Edition or SonarCloud.
Meanwhile, if we were to create a “Suggest new feature” to have a field “date issue first found”, what are the chances of it being implemented in upstream SonarQube? Or if we create a Pull Request as per the guidelines, what are the chances of it being approved?
Ehm… To be entirely candid, since this is a mainly irrelevant detail through the lens of Clean as You Code, you would need to make a pretty compelling case and/or gather a lot of community support for it.
Kudos for being willing to do this! I really do appreciate that. Unfortunately, there are 2 factors at work against you here. First, we generally no longer accept contributions on SQ itself anymore (I think that’s made clear in the guidelines on the GH repo). But beyond that if we did accept it, maintenance would obviously fall to us. And since it’s not a feature that fits with our … “worldview” the odds aren’t good. Unless, as outlined above, you can change our view of things.
