chore: Use CircleCI native timing-based test splitting for acceptance shards

[danskmt]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages are release-note ready, emphasizing what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

Replaces Jest's --shard with CircleCI's native circleci tests run --split-by=timings so acceptance test shards are automatically balanced by historic runtime data — no manually maintained weight files needed.

• Replaces --shard=<index>/<total> with circleci tests glob | circleci tests run --split-by=timings --timings-type=file in the acceptance-tests job.
• Adds addFileAttribute: true to jest-junit config so JUnit XML includes file="..." on each <testsuite>, which CircleCI needs for file-based timing matching.
• Switches the Windows test step to bash.exe (from PowerShell) since the command uses xargs and Unix pipe syntax. Sources the bash-compatible env script (snyk-env.sh) instead of the PowerShell one.

Where should the reviewer start?

• .circleci/config.yml — the acceptance-tests job definition (replaced shard_calc_cmd parameter with test_shell, new circleci tests run command)
• package.json — addFileAttribute addition in jest-junit config

How should this be manually tested?

1. Push branch and trigger CI.
2. Check that acceptance tests run on all platforms (linux, macOS, Windows).
3. Compare shard wall times — after 1-2 runs, CircleCI accumulates timing data and balances shards automatically.

What's the product update that needs to be communicated to CLI users?

None. CI-only change; no CLI behavior change for end users.

Risk assessment (Low | Medium | High)?

Medium — changes how tests are distributed across CI shards on all platforms including Windows (shell change). First run may use name-based splitting until CircleCI accumulates timing data from JUnit reports.

Any background context you want to provide?

CircleCI stores timing data per job name across all branches, so existing store_test_results uploads from main should provide immediate timing data. The addFileAttribute flag makes jest-junit emit the file attribute on each <testsuite>, enabling CircleCI to match timing history to spec files. See CircleCI docs: Test splitting and parallelism.

What are the relevant tickets?

CLI-1482

Screenshots (if appropriate)

Before (main) X Now (chore/CLI-1482-circleci-native-test-splitting):

Before (feat/CLI-1482-balance-acceptance-test-shards) X Now (chore/CLI-1482-circleci-native-test-splitting)

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[robertolopezlopez]

LGTM! Good job

[danskmt]

We need this addFileAttribute: true to jest-junit config so JUnit XML includes file="..." on each , which CircleCI needs for file-based timing matching.

[j-luong]

I think introducing bash as the shell for Windows causes more problems than it solves, let's see if we can do this without needing bash for Windows. That way we can clean up the extra scripts you introduced

[danskmt]

@j-luong it seems we do need the path thing... Needs both for saving as forward slash, and for normalizing when fetching
https://app.circleci.com/pipelines/gh/snyk/cli/37803/workflows/6ad62f25-703d-42a3-aad8-8401d73bb71d/jobs/595269

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Logic Error 🟠 [major] The PR description states that acceptance tests on Windows were switched to bash.exe to support xargs, yet the test_cmd override for the Windows job (lines 1006-1008) uses PowerShell-specific syntax (Get-ChildItem, ForEach-Object, -replace). If the job executor is running bash, this command will fail. Conversely, if it remains in PowerShell, xargs (referenced in the command string at line 1008) is not a native command and may fail unless specifically provided in the environment. Get-ChildItem -Recurse -Path test/jest/acceptance,ts-binary-wrapper/test/acceptance -Filter *.spec.ts | ForEach-Object { (Resolve-Path -Relative $_.FullName) -replace '\\', '/' -replace '^\./', '' } | circleci tests run --command "xargs npx jest --maxWorkers=1 --selectProjects coreCli --reporters=jest-junit --reporters=default --" --split-by=timings --timings-type=file Potential Data Corruption 🟡 [minor] The regex /file="[^"]*"/g used to find path attributes in JUnit XML is overly broad. It matches the string file="..." anywhere in the XML file, including within test failure messages, standard output, or error logs captured in the report. If a test failure message contains a backslash within a quote preceded by file=, it will be unintentionally modified to a forward slash, potentially corrupting the reported error details for developers. const fileAttrPattern = /file="[^"]*"/g;

📚 Repository Context Analyzed This review considered 7 relevant code sections from 6 files (average relevance: 0.81) dangerfile.js (lines 1-111) CONTRIBUTING.md (2 segments, lines 1-231) scripts/normalize-junit-file-paths.js (lines 1-46) package-lock.json (lines 6-266) packages/snyk-fix/jest.config.js (lines 1-4) package.json (lines 1-229)

🤖 Repository instructions applied (from AGENTS.md)