refactor: create only one project group per execution

[francescomari]

• Follows CONTRIBUTING rules

What does this PR do?

This PR changes the behaviour of the iac test command when multiple paths are passed on the command line. This PR changes the behaviour of the --report flag, too. The implemented behaviour is the following:

• iac test recursively scans the current working directory by default.
• If one or more paths are passed on the command line, those paths must be relative to the current working directory.
• If one or more paths are passed on the command line, only those files or directories are scanned. If a path is a directory, it will be recursively scanned.
• If the --report flag is used, the iac test command creates one project group in the platform named after the name of the current working directory.
• If the current working directory is a Git repository, additional information will be extracted and attached to the projects and the project group.

Where should the reviewer start?

This PR extracts the scan logic into src/cli/commands/test/iac/scan.ts. You can start the review fro there.

How should this be manually tested?

Move anywhere on the file system and run snyk iac test ... The command will fail with an error, because the only provided path is outside of the current working directory.

$ snyk iac test ..

Testing .....

Path ".." is outside the current working directory

Move in the root of this repository and run snyk iac test --report. This command creates only one project group in the platform, named after this repository. All the project names will be the paths of the IaC files in this repository, relative from the current working directory.

Move into the test/fixtures/iac directory and run snyk iac test --report. The command creates only one project group named iac, because the current working directory is not a Git repository. All the project names are relative from the current working directory.

Any background context you want to provide?

This behaviour has been discussed in this document. The document contains additional links to interesting conversations that shaped the implementation in this PR.

What are the relevant tickets?

CFG-1840

[ipapast]

We had a chat with @francescomari and Esra regarding the expected design and also some edge cases that fail, such as snyk iac test . .. --report.
Francesco is making some changes and we are going to review again

[francescomari]

@ipapast I added a new error class in scan.ts. That will need to be updated as soon as we have more details by the content team.

[ipapast]

@francescomari I tested different scenarios we discussed on the call, including snyk iac . .. --report and they all look good now.

But I also tried out something more weird, like:

cwd=/Users/iliannapapastefanou/snyk-repos/snyk/test/fixtures/iac/terraform

Then run:

snyk-dev iac test . .. ../arm/ var_deref --report

You will see in the last line a project name appearing as 'var_deref" which is not true. When I check the platform everything is correctly grouped under "snyk"

[francescomari]

@ipapast that was a really good catch. It should be fixed at 73d30c66, according to the unit tests. Let's see what the acceptance tests say.

[ipapast]

@ipapast that was a really good catch. It should be fixed at 73d30c6, according to the unit tests. Let's see what the acceptance tests say.

they pass now and running it manually looked good 👍 I'll approve and let's see how the product discussion goes.

[francescomari]

Given the latest conversations about this feature, the scope of this PR changed. Instead of replacing the current implementation for processing results, the PR adds a new implementation (single project group) in src/cli/commands/test/iac/local-execution/process-results/v2 and keeps the old one (multiple project groups) as-is in src/cli/commands/test/iac/local-execution/process-results/v1.

The code in src/cli/commands/test/iac/scan.ts choses the implementation at runtime depending on the presence of a projectRoot. Because no projectRoot is currently passed to scan(), the new implementation is inactive and the old one is still in use, as before.

I could have been more granular when splitting the two implementations, but I decided not to at the cost of some code duplication. When the new implementation will become the default, removing the old one will be as easy as deleting the v1 module, removing the class MultipleGroupsResultsProcessor, and adjusting scan(). I didn't want to introduce granular if statements buried deep in the implementation of the result processor. In this case, I believe that some code duplication makes the code easier to maintain.

Some tests are missing for SingleGroupResultsProcessor. I will add those in a separate PR.