fix(ci): weekly self-scan installs the checkout, not a stale v0.5.4 tag - #106
Merged
Conversation
The `Signetry auto-fix` workflow installed signetry-core from `git+https://github.com/Signetry/core@v0.5.4`. That tag predates the umbra -> signetry rename, so its metadata still declares `name = "umbra-core"`, and pip refused the requested `signetry-core`: Requested umbra-core from git+.../core@v0.5.4 has inconsistent name: expected 'signetry-core', but metadata has 'umbra-core' ERROR: No matching distribution found for signetry-core (unavailable) Every scheduled run since the rename failed at the install step, so the scan, the leak check and the PR step were all skipped. This is the signetry-core repo, so install the checkout (`pip install .`): the weekly self-scan should exercise the code on main, and a hard-coded tag drifts behind it by construction. Downstream consumers still install by tag (see Signetry/autofix-demo, already on v0.7.0). Also make the artifact path deterministic. `path: ${{ env.OUT }}/...` only resolves after the scan step exports OUT, so a failure before that point made it upload from `/scan-and-fixes.json`. Verified locally on 3.13: `pip install .` yields signetry-core 0.7.0 with a working `signetry` entry point, and `signetry --json scan .` exits 0 with 9 findings.
Signetry Reviewer — 🟣 Escalate to a designated reviewerEscalate to a designated reviewer — this PR touches security-sensitive surface (.github/workflows/signetry-autofix.yml). No blocking issue was found automatically, but a human owner should sign off. Deterministic gates (the authority)
Findings (1, 0 blocking)
Sensitive surfaceThis PR changes security-sensitive paths that warrant a designated reviewer:
MergeA designated reviewer / code owner should sign off before merge (sensitive surface).
|
bkd-dotcom
added a commit
that referenced
this pull request
Sep 1, 2026
#106 fixed why the weekly governed self-scan was failing. This fixes why nobody knew — which is the more interesting half. The scan failed on 2026-08-17, 2026-08-24 and 2026-08-31, three consecutive Mondays, and was only discovered because a human went looking at the run list. A scheduled job that fails silently is indistinguishable from one that never ran, and treating an absent signal as a passing one is exactly the mistake this engine exists to catch. It should not have been our own weekly job doing it. A failing scheduled run now files a report: - Only for `schedule`. A failed workflow_dispatch is already in front of the person who clicked it; filing an issue at them would be noise, and noise is how the first three failures got ignored. - One issue, reused. A fresh issue every Monday would bury the signal it exists to raise, so an already-open report gets a comment instead. - The label is created first, because `gh issue create --label` fails outright on a label that does not exist. - `issues: write` is scoped to this job alone. It gets nothing else — notably not the contents/pull-requests write the scan job holds. The report states plainly that no fix PRs were opened and nothing was merged, so reading it cannot leave anyone unsure whether a half-finished change landed.
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
1 participant
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 failure
Every scheduled run of Signetry auto-fix (branch-only PR with receipt) has failed since the
umbra→signetryrename — most recently run 33392468703 (2026-08-31) and run 32698978560 (2026-08-24).The
Install Signetrystep pinned the package to a pre-rename tag:v0.5.4'spyproject.tomlstill declaresname = "umbra-core", so pip rejected the name mismatch:Because install failed, the four steps that matter — scan + propose fixes, the credential-leak gate, and the branch-only PR step — were all skipped. The job was failing silently at setup, not finding nothing.
The fix
This is the
signetry-corerepo, so install the checkout instead of a published tag:A hard-coded tag in a repo's own self-scan drifts behind
mainby construction — this bug would recur at every rename or release. Installing the checkout also means the weekly self-scan exercises the code actually onmain, which is what a self-scan is for. Downstream consumers keep installing by tag (Signetry/autofix-demois already onv0.7.0).Second, smaller fix: the artifact path was
${{ env.OUT }}/scan-and-fixes.json, butenv.OUTis only exported once the scan step runs — so any earlier failure made it resolve to/scan-and-fixes.json. It is now the deterministic${{ runner.temp }}/signetry/scan-and-fixes.json.Verification
Clean venv on Python 3.13:
pip install .→signetry-core 0.7.0,signetryentry point presentsignetry --json scan .→ exit 0, 9 findings (8 high / 1 medium).github/**is already inallowed_pathsin.signetry/admission.yaml, soself-admissionis unaffected.