Repository navigation
ci: pin semgrep to 1.175.0 and screen its install - #50
Merged
Merged
Conversation
hironow
force-pushed
the
ci/semgrep-pin
branch
from
September 4, 2026 11:34
4d5c38a to
9daf780
Compare
`pipx install semgrep` took whatever was newest at run time, so a semgrep release could turn CI red on a commit that changed nothing -- a new or widened rule needs no commit behind it to start failing. `uv tool install semgrep==1.175.0` makes the version a decision instead of a coincidence. The job also gains the Takumi Guard step every other install-bearing job has, placed before `uv tool install` so the install resolves through the screened index rather than PyPI. This job was the last unscreened install in the repo. 1.175.0 rather than the newest: it is on the proxy, and it is older than the seven-day `exclude-newer` window the project applies everywhere else. 1.176.0 satisfied neither -- the proxy carries only up to 1.175.0, and 1.176.0 shipped 2026-09-01, inside the window -- so pinning it would have meant a version the project's own supply-chain rules reject. The comment on the step says so, for whoever raises it next. setup-uv is added to the job, SHA-pinned to the same v10.0.1 and uv 0.11.17 the other jobs use. Job names are unchanged. Verified at 1.175.0: `just semgrep-test` passes 3/3 rules, `just semgrep` reports 0 findings over 21 targets, and `just ci` is green. The verification resolved 1.175.0 with no index or cutoff override, through a uv configured for the screened index and the seven-day window -- which is itself the proof the version satisfies both rules. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LXPmm8VuMHBjo4Q6k7tRtq
hironow
force-pushed
the
ci/semgrep-pin
branch
from
September 4, 2026 11:38
9daf780 to
2bbf7e0
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.
Owner decision Q44(a), revised to 1.175.0 after the version check. One
ci:commit.
Why
pipx install semgreptook whatever was newest at run time. semgrep gatesmerges, so a release could turn CI red on a commit that changed nothing — a new
or widened rule needs no commit behind it to start failing.
The job also gains the Takumi Guard step every other install-bearing job has,
placed before
uv tool installso the install resolves through the screenedindex rather than PyPI. This was the last unscreened install in the repo.
Why 1.175.0 and not the newest
1.176.0 would have been a version the project's own supply-chain rules reject,
on two independent counts:
exclude-newerwindowWith Takumi Guard now in this job, pinning 1.176.0 would not merely have been
inconsistent — it would have failed outright. The step comment records the rule
for whoever raises it next: pick a version the proxy carries and that is older
than the window.
CI evidence
Takumi Guard configures the job's index:
and the install resolves through it:
Local verification
Run against semgrep 1.175.0 — the machine's own semgrep is 1.162.0 and was
left untouched.
just semgrep-testjust semgrepjust cicheck-yamlWorth noting how that verification resolved: with no index or cutoff
override, through a uv configured for the screened index and the seven-day
window. Getting 1.175.0 that way is itself the proof it satisfies both rules —
the same command could not produce 1.176.0.
Job names unchanged; the
protectruleset matches its eleven required checks byname.
Docs
docs/release.md: CI pins semgrep to 1.175.0 and installs it through thescreened index; Dependabot does not track it, so raising the version is a
deliberate edit — pick one the proxy carries and that is older than the
seven-day window.
docs/handover.mduntouched.🤖 Generated with Claude Code
https://claude.ai/code/session_01LXPmm8VuMHBjo4Q6k7tRtq