Investigate scalable way to update sonar_issues.json

[clavedeluna]

What

The sonar_issues.json file is used for running integration tests on sonar codemods. We desire this file to be as similar to an actual file coming from a sonar tool.

Pain Points

Currently there are many issues with having this file:

1. it's difficult to keep it up to date. When adding a new sonar codemod, there is no enforcing mechanism to remind us to update this file with an issue for this new codemod. See fix-missing-self-or-cls is missing self.node_is_selected check #413 New assertions to sonar integration tests were added in Sonar tmpfile codemod #393 to ensure we update sonar_issues.json
2. Updating this file is done manually or with a personal script. The file originally came from a curl request to the pixee sonar cloud which contained the code samples under tests/samples. An additional script ran on that file to update the file paths. But none of this is part of a repo-wide process.
3. Unlike other integration tests, sonar integration tests still need the files in tests/samples to match with sonar_issues.json. Recent work tried to move all integration tests to use temp files instead of files stored in disk/git.

Solutions

The real end goal here is if we have some python code snippet, we could easily ask sonarcloud what issues/security hotspots it may find. This sounds magical, but is there a way to make a request to the sonarcloud API like this? We should rule this out first. Because if this exists, we could make this request be part of every integration test, without needing any code files.

A second solution would continue using files in disk, but we would be making a request to the sonarcloud API and filter any existing issues/security hotspots by file name. It would look like this:

1. for existing codemods/tests, every integration test would make a request to https://sonarcloud.io/api/... and look for the issue/hotspot corresponding to the code file in tests/samples. This request would get us the data we need such as textRange so applying the codemod would correctly run.
2. For developing a new sonar codemod, we would create the integration test but it would fail at the step when making the request to sonarcloud because the file in tests/samples doesn't yet exist in sonarcloud (since you're still developing the codemod locally). This would prompt you to push your code and run sonarcloud. Then the test should run normally.