/
/
/
# What does this implement/fix? The dependency security check ignores vulnerability findings that the PR's own resolved dependencies don't contain. That filter exists because the test environment is installed before either branch is resolved, so a release published in between would otherwise be blamed on the PR. Until now nothing said *which* findings were skipped, so the report just read "the findings above are not ones this PR introduces". That makes a genuine timing artifact indistinguishable from a finding that was wrongly cleared, and a maintainer has no way to tell them apart. The check now names those findings and says what the PR resolves to instead, for example: > ℹ️ Not counted against this PR, because its own resolved dependencies do not carry them: `aiohttp 3.14.1` (resolved to 3.14.3), `transformers 5.14.1` (not in the resolved set). **Related issue (if applicable):** - follow-up to #5462 ## Types of changes <!-- Tick exactly one box. CI (.github/workflows/pr-labels.yaml) derives the label from the ticked box and applies it automatically; the release-notes generator uses that same label to slot this change into the next release notes. --> - [ ] Bugfix (non-breaking change which fixes an issue) — `bugfix` - [ ] New feature (non-breaking change which adds functionality) — `new-feature` - [ ] Enhancement to an existing feature — `enhancement` - [ ] New music/player/metadata/plugin provider — `new-provider` - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) — `breaking-change` - [ ] Refactor (no behaviour change) — `refactor` - [ ] Documentation only — `documentation` - [ ] Maintenance / chore — `maintenance` - [x] CI / workflow change — `ci` - [ ] Dependencies bump — `dependencies` ## Changes - `audit_changed_packages.py` names the set-aside findings on stderr, along with the version the PR's resolution carries (or that it carries none) - The workflow appends that note to the scan report and keeps it in the job log; stdout still carries only the status it gates on - A failed scan puts its traceback in the log only, not in the PR comment - Tests cover the note, the case where nothing is set aside, and stdout staying clean ## Checklist - [x] The code change is tested and works locally. - [x] `pre-commit run --all-files` passes. - [x] `pytest` passes, and tests have been added/updated under `tests/` where applicable. - [ ] For changes to shared models, the companion PR in `music-assistant/models` is linked. - [ ] For changes affecting the UI, the companion PR in `music-assistant/frontend` is linked. - [x] I have read and complied with the project's [AI Policy](https://github.com/music-assistant/.github/blob/main/AI_POLICY.md) for any AI-assisted contributions. - [ ] I have [raised a PR against the documentation repository](https://github.com/music-assistant/music-assistant.io/blob/main/CONTRIBUTING.md) targeting the main or beta branch as appropriate.