test: cover --include-component-metadata for poetry projects

[calhar-snyk]

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?

Adds acceptance coverage for snyk test --include-component-metadata on poetry
projects, so the flag's behaviour is pinned for python the way it already is for
npm, maven, go and yarn.

Test-only — no product code changes. The CLI already forwards
--include-component-metadata into plugin options through its generic
single-plugin path (get-single-plugin-result.ts), and poetry rides that same
path, so nothing in src/ needed touching. This PR is the missing test.

• test/jest/acceptance/snyk-test/poetry-include-component-metadata.spec.ts —
  mirrors npm-include-component-metadata.spec.ts: asserts hash: and
  distribution:url labels appear on the printed dep-graph with the flag, and
  are absent without it.
• test/fixtures/poetry-include-component-metadata/ — a pyproject.toml +
  poetry.lock pair. The hashes live in the lockfile, so no poetry install or
  network access is needed.

Risk assessment: Low — test and fixture only; no runtime code paths change.
No breaking API changes.

⚠️ Blocked on two upstream releases (what a taker-over needs to do)

This PR deliberately contains no version bumps. The assertions only pass once
the poetry parser emits the labels and the python plugin threads the flag:

1. snyk-poetry-lockfile-parser — feat: emit component-metadata (hash/distribution) labels for SBOM export snyk-poetry-lockfile-parser#43
2. snyk-python-plugin — feat: emit component-metadata labels for poetry projects snyk-python-plugin#376 (bump the parser there first)

Once both are published, bump snyk-python-plugin in package.json (currently
^3.2.1) to the release containing (2). Until then this spec fails — the
published plugin ignores the flag, so no labels are produced. That failure is
expected and is the only thing between this and mergeable; no other work is
outstanding.

Where should the reviewer start?

The spec file — it's a close copy of the npm sibling, with two poetry-specific
differences worth a look:

• Only one project is scanned (no npm-workspaces equivalent), so there's no
  --all-projects case.
• distribution:url for poetry is a PEP 503 project-page URL with a
  #<filename> fragment (e.g.
  https://pypi.org/simple/jinja2/#Jinja2-2.11.2-py2.py3-none-any.whl), not a
  direct download URL like npm's registry tarball — poetry.lock never records
  one. The assertion matches that shape deliberately.

How should this be manually tested?

With local checkouts of the two upstream repos wired in:

# parser (PR 43 branch) and plugin (PR 376 branch), each: npm ci && npm run build
# point the plugin at the local parser, then here:
npm pkg set dependencies.snyk-python-plugin=file:/abs/path/to/snyk-python-plugin
npm install && npm run build:dev   # a rebuild is required: dist/ is webpacked
npx jest test/jest/acceptance/snyk-test/poetry-include-component-metadata.spec.ts

Note test:acceptance needs a SNYK_TOKEN (the spec runs a real snyk test);
without one it exits 2, exactly as the existing npm/maven component-metadata
specs do locally.

The label behaviour itself was verified through the built binary:

cd test/fixtures/poetry-include-component-metadata
node ../../../bin/snyk test --print-graph --file=poetry.lock --include-component-metadata
# jinja2   -> hash:sha-256 f0a4641d… + https://pypi.org/simple/jinja2/#Jinja2-2.11.2-py2.py3-none-any.whl
# markupsafe -> hash:sha-256 29872e92… + https://pypi.org/simple/markupsafe/#MarkupSafe-1.1.1.tar.gz
# without the flag: labels are just {"scope":"prod"}

(markupsafe publishes no universal wheel, so it resolves to its sdist — the
fixture exercises both branches of the parser's artifact selection.)

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

None for this PR — it is test-only. The user-facing change (poetry SBOMs gaining
component hashes and distribution URLs) ships with the parser/plugin releases
listed above and should be announced alongside those.

What are the relevant tickets?

CMPA-656

[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.

[github-actions]

	Warnings
⚠️	There are multiple commits on your branch, please squash them locally before merging!

Generated by 🚫 dangerJS against 20078dd