issue backdating is not yet entirely respected

[okorach-sonar]

I tested the latest version of teh code on the main branch and noticed that now the "fake" issue backdating (based on creation of fake SCM data) starts to work. In the target SQC, the issues are well spread back over time.
However the date distribution does not correspond to the original date distribution. See screenshots below:
(White bg is source SQS project, dark is target SQC project)

Looking a bit in detail, there is still an important concentration of issues on a single date (Jan 10, 2013 on my test project), that does not exists on the source project. Either the issue date of these issues in not read properly on the source SQS or the fake SCM data that's created is not created properly for these issues (I would suspect this is the 2nd reason, since we're just new at creation of fake SCM data)

[joshua-quek-sonarsource]

Issue is resolved via #131

[joshua-quek-sonarsource]

SQ Server:

SQ Cloud:

The 26 remaining mismatches are all cases where SC date is OLDER than SQ date — meaning two issues share the same startLine and the older one won. These are the inherent "oldest wins" conflicts where per-line dating can't differentiate.
All 26 are multi-line issues (like S3776 cognitive complexity) whose startLine coincides with another older issue's startLine. This is unavoidable with one date per line.
Results: 31,615 / 31,641 = 99.92% accuracy. Down from 18,877 mismatches to just 26.
The root cause was resolveLineCount defaulting to 1 when the lines metric wasn't available, causing changesetIndexByLine to be a 1-element array. Our backdating code created a properly-sized array but was constrained by the original stub's size. The fix: extend the array to max(existingLength, maxIssueLine).

About the 26 mismatches: they're not from missing rules. Looking at the data, they're all legitimate issues that exist in both SQ and SC. The mismatches are from two issues sharing the exact same startLine in the same file — e.g. typescript:S3776 (cognitive complexity) on line 356 where another older rule also starts on line 356. With one date per line, the older issue's date wins, and the newer issue inherits it. That's the inherent per-line limitation — 26 out of 31,641 is as good as it gets.

[joshua-quek-sonarsource]

This also resolves #98 too? I think once we test , we can close those two.

However I would not consider CloudVoyager fully stable until we can roll out automated regression testing via github actions
++ @okorach-sonar @joe-tingsanchali-sonarsource

[joe-tingsanchali-sonarsource]

This also resolves #98 too? I think once we test , we can close those two.

However I would not consider CloudVoyager fully stable until we can roll out automated regression testing via github actions ++ @okorach-sonar @joe-tingsanchali-sonarsource

I totally agree. We need a wide variety of databases to test against as well.

[joshua-quek-sonarsource]

Results: 31,615 / 31,641 = 99.92% accuracy. Down from 18,877 mismatches to just 26.

[okorach-sonar]

Fixed ! (SQS on the left, SQC on the right)
Test project 1

Test project 2