Remove the merge-blocking pip-audit dependency gate - #193
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #193 +/- ##
=====================================
Coverage 2.29% 2.29%
=====================================
Files 4 4
Lines 131 131
=====================================
Hits 3 3
Misses 128 128 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The "Dependency check" step ran `pip-audit --local -s osv` inside the Unit tests job, so it could block a merge. Because pip-audit queries the live OSV database, a newly published advisory armed the gate with no change to the code, and the failure surfaced on whichever contributor opened the next pull request. Clearing it meant adding another version floor to pyproject.toml -- twelve had accumulated that way, spread across four dependency sections. Dependency scanning stays, report-only: the conda-build job still runs Grype and uploads SARIF to the Security tab, matching the non-blocking posture used across the rest of the fleet. Removes the workflow step, the `audit-deps` task, and the `pip-audit` developer dependency (dropping it and its transitive tree from pixi.lock). The existing version floors are kept deliberately -- they keep a fresh environment off known-bad releases -- with a comment noting nothing enforces or refreshes them now. README documents the report-only posture and how to add pip-audit back as a local task. Assisted-With: Claude Opus 5 (1M context) <noreply@anthropic.com>
KedoKudo
force-pushed
the
remove-pip-audit-gate
branch
from
July 28, 2026 16:19
a6bfbbc to
5f77cb8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
Dependency checkstep ranpip-audit --local -s osvas a plain step inside the Unit tests job, which made it merge-blocking. Becausepip-auditqueries the live OSV database, a newly published advisory could arm the gate with no change to the code — and the red X then landed on whichever contributor happened to open the next pull request. Clearing it meant adding another minimum-version floor topyproject.toml; twelve had accumulated that way, spread across four dependency sections.Dependency scanning is not going away, it just becomes report-only: the
conda-buildjob still runs Grype and uploads SARIF to the Security tab. That matches the non-blocking posture already used across the other managed repositories, so the template no longer ships a merge-blocking dependency scan.Changes
.github/workflows/test_and_deploy.yaml— drop theDependency checkstep.pyproject.toml— drop theaudit-depstask and thepip-auditdeveloper dependency.pixi.lock— regenerated;pip-auditand its transitive tree are gone (−243/+20, removals only, no dependency churn).README.md— the "Auditing dependencies" section now documents the report-only posture and shows how to addpip-auditback as a local, on-demand task for projects that want one.The version floors are kept
All twelve stay, deliberately — removing them would quietly let a fresh environment resolve back onto known-vulnerable releases, which is a separate decision from removing the gate. They are now simply unenforced: nothing in CI checks or refreshes them, and a stale floor cannot fail a build. A comment above the main block says so.
[tool.pixi.dependencies]h2,brotli,urllib3,filelock,virtualenv,cryptography,requests,pillow,msgpack-python[tool.pixi.pypi-dependencies]jaraco-context[tool.pixi.feature.test.dependencies]pytest[tool.pixi.feature.developer.dependencies]pipNote
virtualenv = ">=20.36.1,<21"— the<21cap is a hatch compatibility constraint, not a CVE floor. Do not strip it if the floors are ever cleaned up.Verification
All run locally on this branch:
pixi run test→1 passedpixi run pre-commit run --all-files→ 14 hooks pass (incl.check toml,check yaml,yamllint,taplo-format)pixi install --frozen --skip examplepyapp→ succeeds, so the regenerated lock is consistent with the manifest (CI installs with--frozen)pixi run build-docs→build succeededpixi task list→audit-depsabsent; the README task listing was updated to matchtestsjob no longer containsDependency check, andScan installed environment with Grypeis still present inconda-build🤖 Generated with Claude Code