feat: parallelize container test dependency requests#6747
feat: parallelize container test dependency requests#6747
Conversation
Co-authored-by: bgardiner <bgardiner@users.noreply.github.com>
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Co-authored-by: bgardiner <bgardiner@users.noreply.github.com>
Co-authored-by: bgardiner <bgardiner@users.noreply.github.com>
Co-authored-by: bgardiner <bgardiner@users.noreply.github.com>
Co-authored-by: bgardiner <bgardiner@users.noreply.github.com>
|
Closing — this PR targets the wrong code path for The PR modifies
The unit test in this PR confirms the rewrite works if The actual win for container test is to bump the concurrency limit at the existing ( |
|
Closing — wrong code path. See review comment above. Container test is already parallel; the actual fix is bumping the concurrency limit (#6756). |
Pull Request Submission Checklist
are release-note ready, emphasizing
what was changed, not how.
What does this PR do?
This PR updates request dispatch in the active
snyk container testpath (src/lib/snyk-test/run-test.ts) and keeps request execution parallelized via the existing pMap concurrency limit (MAX_CONCURRENCY = 5).Important routing correction
A previous iteration targeted
src/lib/ecosystems/test.ts, butsnyk container testcurrently routes through the legacy test flow (snyk-test/run-test.ts), not that ecosystems test function. This PR keeps changes in the correct path.Where should the reviewer start?
src/lib/snyk-test/run-test.tsHow should this be manually tested?
npm run lintnpm run test:unit -- --runTestsByPath test/jest/unit/ecosystems-monitor-docker.spec.tssnyk container test <image>What's the product update that needs to be communicated to CLI users?
Container test request orchestration changes are applied in the active legacy test path used by
snyk container test.Risk assessment (Low | Medium | High)?
Low. The final change is narrowly scoped and maintains existing container request parallelism semantics.
Any background context you want to provide?
The branch previously introduced a base-first ordering strategy for container payloads, but that was intentionally removed.
What are the relevant tickets?
N/A