mirror of
https://github.com/semantica-agi/semantica.git
synced 2026-09-03 04:00:18 +00:00
Mohd Kaif
b0679d4f67
* fix(ci): drop unpinnable benchmarks/requirements.txt install Scorecard flagged this pip install as unpinned-by-hash (#6082). Can't hash-pin it - benchmarks/requirements.txt doesn't exist in this repo, so there's nothing to compile a lockfile from. Dropping it instead of leaving it unpinned: the job already fails on the next real step (benchmarks/benchmarks_runner.py, also missing), so this line wasn't doing anything useful to begin with. * fix(ci): hash-pin the spacy model download in benchmark.yml Qodo review on this PR: dropping the benchmarks/requirements.txt install (the previous failure point) let the job actually reach `python -m spacy download en_core_web_sm`, which fetches an unpinned, unhashed wheel from spacy-models' GitHub releases - undoing the point of this PR by exposing a real unpinned-install path instead of a dead one. Replaced with a hash-pinned direct-URL entry in benchmark-extra.in/.txt for en_core_web_sm-3.8.0 (matches the spacy==3.8.15 already pinned in base-deps.txt). uv independently computed the same sha256 I got via a manual curl+sha256 of the release asset, and a --require-hashes dry-run install verifies clean. * fix(ci): stop checkov's suppressed checks from reopening as new alerts Root cause found, not just worked around: checkov's SARIF exporter includes every evaluated check as an ordinary result, including ones it internally marked SKIPPED via the inline # checkov:skip= comments and checkov.io/skipN annotations already on the Helm chart. It never uses SARIF's own `suppressions` field and never drops them - so the exact same already-suppressed finding reopens as a brand-new code scanning alert number on every single run, forever (#6035/#6036, #6112-6115, #6128-6131 are all the same 4 findings, manually dismissed 3 times now). checkov's JSON output *does* correctly record which checks were skipped. Added .github/scripts/filter_checkov_skipped.py, which cross-references the JSON's skipped_checks against the SARIF's results (matched by check ID + the last two path segments, since the two outputs use different path roots) and drops anything checkov itself already decided to suppress, before upload. Verified locally against a real checkov+helm run: removed exactly the 4 known-suppressed helm chart results, left the 2 genuinely real findings (deploy/gcp/cloudrun-service.yaml, deploy/kubernetes/ deployment.yaml) untouched.