IaC local execution experimental release #1 - #1601
Conversation
|
067a821 to
913c536
Compare
913c536 to
806b5e6
Compare
fb7cad4 to
51e3e76
Compare
aron
left a comment
There was a problem hiding this comment.
👏 This looks great from my side. Only high level comments I have is that we should better document the entry-point in index.ts to be clear about what this new code path is and that the current code makes many uses of the term "legacy" but nowhere do we say what is legacy or why.
|
|
||
| const readFileContentsAsync = util.promisify(fs.readFile); | ||
|
|
||
| export default async function legacyWrapper(pathToScan: string, options) { |
There was a problem hiding this comment.
Why is this a legacy wrapper? What are legacy results? Can we add types for options and the return value?
There was a problem hiding this comment.
maybe the naming is inaccurate...
I didn't want the old structure and types to dictate how we re-build the new experience.
So this basically just does some "adapter" logic for the results to "plug&play" with the rest of the CLI, which made it easier to achieve lots of extra functionality like the --json & --sarif support.
got ideas for better naming?
There was a problem hiding this comment.
Oh I see, yes let's avoid legacy as the rest of the CLI will continue to use it. How about we refer to the output of this function as the "cli results" and the legacy-adapter.ts as the cli-results-formatter with a comment about how it takes the internal data model and formats it for consumption by the wider snyk cli helpers.
We can just call this function execute() I think or test() with a comment above to explain why it's doing the formatting.
Thoughts?
There was a problem hiding this comment.
removed all use of legacy and renamed.
| } | ||
|
|
||
| return [ | ||
| { filePath: pathToScan, fileType: getFileType(pathToScan) as IacFileTypes }, |
There was a problem hiding this comment.
Can we avoid this cast? Or document why it is needed.
| docId: yamlDocuments.length > 1 ? docId : undefined, | ||
| }); | ||
| } else { | ||
| throw new Error('Invalid K8s File!'); |
There was a problem hiding this comment.
Can we include the missing fields here to help with debugging.
There was a problem hiding this comment.
If we throw in one of the iterations, are we ok w/ throwing away all the process?
There was a problem hiding this comment.
@aviadatsnyk
for now yes, as it supports a single file scan.
when we add directory support (upcoming follow-up work), probably partial results are the right approach, which is also how it works now if I remember correctly..
Anyway, ones of our goal along this migration to the local-exec model, is to align with the experience we currently have today for the iac remote-processing cli flow.
c91706d to
6ef4f48
Compare
aron
left a comment
There was a problem hiding this comment.
👍 Nice work, very excited to see this used internally.
| // } | ||
| // } | ||
|
|
||
| function iacLocalFileScanToFormattedResult( |
There was a problem hiding this comment.
Should return a TestResult type (defined in src/lib/snyk-test/legacy.ts).
There was a problem hiding this comment.
absolutely correct, but for now adding a TODO on these as it's a typing rabbit-hole due to lack of accurate typing down the road in the rest of the CLI..
| // CloudConfigFileTypes, | ||
| // } from '@snyk/cloud-config-parser'; | ||
|
|
||
| export function formatResults( |
There was a problem hiding this comment.
Should return a TestResult[] type (defined in src/lib/snyk-test/legacy.ts).
| const fileDataToScan = await parseFileContentsForPolicyEngine( | ||
| filePathsToScan, | ||
| ); | ||
| const scanResults = await policyEngine.scanFiles(fileDataToScan); |
There was a problem hiding this comment.
maybe worth align this with the evaluate of CCPE (I saw that there is an internal evaluate function there - but maybe there it should be evaluateData or something similar)
There was a problem hiding this comment.
will consider that for next release.
although I don't want to have our old types & terminology restrict us here, as it's an opportunity to rethink naming as well.
There was a problem hiding this comment.
why are we binding to a git commit and not the npm distro?
https://www.npmjs.com/package/@open-policy-agent/opa-wasm
There was a problem hiding this comment.
intentionally.
the package is not mature, and the latest tagged release is missing functionality that we are dependent on.
therefore, until they do a new release, we're targeting a specific commit-hash.
see:
open-policy-agent/npm-opa-wasm#31
There was a problem hiding this comment.
yes, as it is a typing rabbit-hole, and I prefer not having the old types in the CLI dictate how we build the new experience.
+I want to focus on the bare-minimum of fields for the new experience data-structures, and not jam tons of fields just because the main CLI flow requires them.
so this will be typed, but soon :)
| docId: yamlDocuments.length > 1 ? docId : undefined, | ||
| }); | ||
| } else { | ||
| throw new Error('Invalid K8s File!'); |
There was a problem hiding this comment.
If we throw in one of the iterations, are we ok w/ throwing away all the process?
There was a problem hiding this comment.
please use path.sep instead of / :)
There was a problem hiding this comment.
generally I 100% agree.
but keeping these intentionally, as this is logic that will be entered in one of the next follow-up PR's and is commented out due to a blocker.
wrote a comment on it here:
https://github.com/snyk/snyk/pull/1601/files#diff-2e4fd6421898cc5c5947d03530196bee66469cd25276fcdfcc0ba4381268b2c9R44
otherwise it will just get re-implemented soon.
There was a problem hiding this comment.
wanted to do aliasing, but the linter doesn't like it.
replacing with:
export type IacFileMetadata = IacFileInDirectory;
which the linter is ok with.
There was a problem hiding this comment.
we're mainly adapting the standards used here.
@JackuB do you have an answer for that?
There was a problem hiding this comment.
why are we testing this way?
There was a problem hiding this comment.
- it has lots of benefits for E2E integration tests which we can easily cover most of the core flows of our product.
- it's a new testing framework Hammer introduced to the CLI and we are ones of the first to adopt it out.
- our old test-coverage for
test iacare mainly E2E tests which are written in Tap, and are deprecated and no longer maintained. - We will probably add later-on some Jest unit-tests, but for now we're fine with that coverage.
aviadhahami
left a comment
There was a problem hiding this comment.
LGTM.
Please squash commit messages :)
87b270b to
f8bd3f3
Compare
|
🎉 This PR is included in version 1.441.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Revert "Merge pull request #1601 from snyk/feat/iac-experimental-local-exec"
What does this PR do?
This PR adds a new
--experimentalflag to be used withsnyk iac test.It is part of a wider project called Local Execution.
It adds new logic which does issue scanning locally with a provided
.wasmfile that will be manually given to Snykers for a dog-fooding release.This is intentionally not exposed yet under
--help.This flag currently supports the following functionality:
It does not support yet:
Running Locally
In order to run locally, checkout the branch, build and run the local built version.
make sure to have a folder called
.iac-datain your CWD where you're running the CLI from, and have thepolicy.wasm&data.jsonfiles in it (can be found in the attachments of: https://snyksec.atlassian.net/browse/CC-601)TODO