Tags: SocketDev/socket-python-cli
Tags
Bump pinned @coana-tech/cli to 15.10.55 (#375) Co-authored-by: socket-pr-bot[bot] <294242679+socket-pr-bot[bot]@users.noreply.github.com> Co-authored-by: lelia <2418071+lelia@users.noreply.github.com>
Detect manifest changes across the whole pull request range, and fix … …full-scan reporting (#371) * Detect changed files across the whole base..HEAD range Changed-file detection reads a full comparison range only when it recognizes the CI environment: a GitHub pull request, a GitLab merge request, a Bitbucket pull request, or a Buildkite pull request. Every other run falls through to `git show HEAD`, which sees the tip commit alone. That makes dependency gating depend on commit ordering. A pull request whose manifest changed in an earlier commit, followed by a source-only commit, looks like a source-only change: the supported-manifest check fails, the comparison is abandoned for a full scan, and blocking is suppressed, so the run reports no new issues and exits 0. A caller that supplies a base commit has stated the range outright, so honor it ahead of any inference from the environment, reusing the same range detection the recognized providers already use. An unresolvable base commit warns rather than degrading quietly, because the fallback silently narrows the comparison to one commit. * Report full-scan findings as repository findings, not new ones A run with no baseline creates a full scan and suppresses blocking, because there is nothing to compare against and so nothing can be attributed to the change. When an alert-bearing output format is enabled the scan still carries every finding in the repository, and the console summary labeled those `NEW` and their link `Diff Url`. Both are wrong for a full scan, and the first contradicts the exit code: the summary reported blocking issues while the run exited 0, which reads as gating that silently failed rather than gating that correctly did not apply. Label the counts and the link by what the run produced, and say why the counts do not gate. The alert list itself is left alone, since SARIF and JSON output read it and renaming their fields would break consumers. * Stop doubling the namespace in a removed package's purl update_package_values already prefixes a namespaced package's purl with its namespace, so prefixing it again while collecting removed artifacts produced `com.example/widget@1.0.0com.example/com.example/widget@1.0.0`. The purl reaches the dependency overview comment verbatim, so every removed or replaced row for a namespaced package rendered with an unreadable name. The loop collecting added artifacts calls the same function and never did this. * Describe --ignore-commit-files by what it does, and release 2.10.0 The CLI reference described `--ignore-commit-files` as forcing a full scan in four places, and `--help` said only "Ignore commit files". The flag forces a comparison. The confusion is that "full scan" carries two meanings here: the set of files scanned, where the documentation was right, and the scan mode, where it stated the opposite of the behavior. Anyone looking for a way to run a comparison when the changed-file check would skip one would rule out the only flag that does it. Also documents the range that changed-file detection reads, and that supplying a base commit widens it. * Handle explicit base ranges in shallow clones
Bump gitpython to 3.1.62 and soupsieve to 2.9.2 (#365) Both pins are flagged by pip-audit against the current lock: gitpython by CVE-2026-87817, CVE-2026-87818 and CVE-2026-87819, and the transitive soupsieve by GHSA-gjv8-xp57-g29c and GHSA-j934-xhv5-fg8f. Normalize the gitpython requirement to its lowercase PEP 503 name, matching uv.lock and the rest of the pins. Dependabot's uv updater errors on this entry with dependency_file_content_not_changed; the rename is a candidate fix for that. Move pip-audit out of the Unit Tests workflow into a Dependency Audit workflow with a daily schedule. The audit compares the lockfile against databases that publish continuously, so its result tracks the clock rather than the commit and needs a trigger to match. A failing scheduled run has no pull request to report on, so it opens a tracking issue and closes it once the audit is clean. Drop the paths filters from the pull_request triggers on Unit Tests and Version Check. A status check behind a paths filter produces no check context on a pull request that misses the filter, so those jobs cannot be marked required while the filters are in place. The push triggers keep theirs.
PreviousNext