A pull request fails only on the vulnerabilities it brings #62
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: mi/werkregie#62
Reference in New Issue
Block a user
See the PR document.
🤖 Generated with Claude Code
🟠 werkrevisor ORANGE for
cd05b8e, superseded by the result for6fdd118🟠 werkrevisor: ORANGE / FINDINGS
Change kind:
mixed.Reasons
Findings
doc/prs/2026-10-13-PR#62-new-vulnerabilities.md:93, ORANGE, as a line commentClassifier
9 of 9 units passed all questions (1 PR document(s)).
Usage: model `openrouter/minimax/minimax-m3`, LLM done, tokens counted before the call 20551, calls 1, tokens in 19931 / out 17743 (reasoning included in out), duration 104.5 s, cost 0.0272 USD (reported), classifier `jev-1.13.0` calls 9, tokens in 7052, cost 0.0003 USD, finding judge `jev-1.13.0` calls 1, tokens in 1889, cost 0.0001 USD, build file judge `jev-1.13.0` calls 3, tokens in 7594, cost 0.0003 USD, phases: path_judge 0.3 s, classifier 0.7 s, context 0.3 s, model_review 100.9 s, finding_judge 0.2 s, config: defaults + host + repository (.werkrevisor.toml at main1 answer ignored because of a confidence below [classifier] min_confidence.
d679c13).Reviewed head `cd05b8e81211186ea1e1eb330d63c1f2a22e269d` against base `d679c13797c17caa9053da8e2e9e02636c5b9988`, werkrevisor 0.41.1.
werkrevisor: ORANGE / FINDINGS for
cd05b8e81211186ea1e1eb330d63c1f2a22e269d.The result comment of werkrevisor holds the details.
@@ -0,0 +90,4 @@## Follow-up PRs- werkregie shows a vulnerability found on main in "Du bist dran".- The human adds `werkator/dependencies` to the required checks of `main`.[medium] Follow-up contradicts Werkator config (werkrevisor)
ORANGE; Jev: real 0.88, severity 2.6 of 3
The second follow-up says the human will add
werkator/dependenciesto the required checks ofmain, but the Werkatordependenciesbuild is configured withbranches: ["*", "!main"], which excludes main. As written, the build would either never run on main (so the required check would never become green) or Werkator would have to bypass the branch filter; neither is documented. The actual nightly check on main is already done bywerkator/vulnerability-data(which runsdependencyCheckAnalyze), so the follow-up needs to either namewerkator/vulnerability-dataor spell out which configuration change (!mainremoved, a new build, etc.) makeswerkator/dependenciesapplicable to main.No contradiction, but the wording allowed it; clarified in
6fdd118.A required status check of Gitea's branch protection of
mainis required of each pull request into main, on the pull request's head commit; it is never required of commits on main.werkator/dependenciesruns on every branch but main, i.e. on each pull request's head, so it can become green there.Main itself is checked each night by
werkator/vulnerability-data, which runsdependencyCheckAnalyzein full.🟠 werkrevisor ORANGE for
6fdd118, superseded by the result for23cafb9🟠 werkrevisor: ORANGE / FINDINGS
Gate: the approval of mi came before this result; review requested again, please approve again after reading it; merge already scheduled.
Change kind:
mixed.Reasons
Findings
Missing-Lockfile Case Unhandled at
dashboard/build.gradle.kts:157-209, severity unknown, counted as medium, ORANGE, as a line commentstderr Not Drained at
dashboard/build.gradle.kts:165-169, severity unknown, counted as medium, ORANGE, as a line commentClassifier
9 of 9 units passed all questions (1 PR document(s)).
Usage: model `openrouter/minimax/minimax-m3`, LLM done, tokens counted before the call 20472, calls 1, tokens in 19859 / out 29524 (reasoning included in out), duration 143.2 s, cost 0.0414 USD (reported), classifier `jev-1.13.0` calls 9, tokens in 7111, cost 0.0003 USD, finding judge `jev-1.13.0` calls 2, tokens in 5967, cost 0.0003 USD, build file judge `jev-1.13.0` calls 3, tokens in 7594, cost 0.0003 USD, phases: path_judge 0.3 s, classifier 0.6 s, context 0.3 s, model_review 141.1 s, finding_judge 0.3 s, config: defaults + host + repository (.werkrevisor.toml at maind679c13).Reviewed head `6fdd118cb27d489dd6ab956d4d12c7a38f666c11` against base `d679c13797c17caa9053da8e2e9e02636c5b9988`, werkrevisor 0.41.1.
werkrevisor: ORANGE / FINDINGS for
6fdd118cb27d489dd6ab956d4d12c7a38f666c11.The result comment of werkrevisor holds the details.
@@ -140,0 +154,4 @@* i.e. one the pull request adds or changes; the vulnerabilities main has already are named, but fail nothing,* so that a vulnerability found anew stops no unrelated work. Main itself is checked each night in full.*/val checkNewVulnerabilities = tasks.register("checkNewVulnerabilities") {Missing-Lockfile Case Unhandled, severity unknown, counted as medium (werkrevisor)
ORANGE; Jev: real 0.82, severity 2.6 of 3
The
checkNewVulnerabilitiestask derivesknownfromgradle.lockfileat the merge base. This PR is the first to addgradle.lockfile, so when the CI runs against-PvulnerabilityBaseline=origin/main, the merge base has no lockfile,git showfails, andknownis empty. Every vulnerability found in the current runtime classpath is then partitioned intobroughtand fails the build, even though the PR adds no vulnerable dependency. The code must handle the missing-lockfile case (e.g., skip the check or treat all entries as on main), or the lockfile has to land onmainin a prior PR. The impact depends on whether the current dependencies have any CVSS 4+ vulnerability; if they do, the PR cannot be merged as written.No change of the rule, made visible in
23cafb9: a merge base without lockfile counts each vulnerability as new, the safe side, as the comment says; the build now logs this case.Only branches from before the lockfile meet it, and this PR's own check finds no vulnerability: on Werkator,
werkator/dependenciesofcd05b8ewas green ("0 on main"), and locally against origin/main: "no vulnerability from CVSS 4.0 ... 0 on main".Skipping the check, or counting everything as on main, would let exactly these branches bring a vulnerable dependency unchecked.
@@ -140,0 +162,4 @@val baseline = vulnerabilityBaselineval projectDir = layout.projectDirectory.asFiledoLast {fun git(vararg args: String): String? {stderr Not Drained, severity unknown, counted as medium (werkrevisor)
ORANGE; Jev: real 0.81, severity 2.8 of 3
The local
githelper reads stdout withreadText()but never consumes stderr (redirectErrorStream(false)). If agitinvocation writes more than the OS pipe buffer to stderr (e.g., a verbosegit showerror on the missing lockfile in the base), the child process blocks until the CI's 10-minute timeout. Draining stderr in another thread (or merging it into stdout) is the defensive fix.Fixed in
23cafb9: git's stderr goes to Redirect.DISCARD, so it cannot fill its pipe; a failure still shows in the exit code.New commits pushed, approval review dismissed automatically according to repository settings
🟡 werkrevisor: YELLOW / HUMAN_REVIEW
Change kind:
mixed.Reasons
Classifier
9 of 9 units passed all questions (1 PR document(s)).
Usage: model `openrouter/minimax/minimax-m3`, LLM done, tokens counted before the call 20666, calls 1, tokens in 20047 / out 34594 (reasoning included in out), duration 189.8 s, cost 0.0475 USD (reported), classifier `jev-1.13.0` calls 9, tokens in 7111, cost 0.0003 USD, build file judge `jev-1.13.0` calls 3, tokens in 7681, cost 0.0003 USD, phases: path_judge 0.3 s, classifier 0.6 s, context 3.6 s, model_review 184.3 s, config: defaults + host + repository (.werkrevisor.toml at maind679c13).Reviewed head `23cafb9c013b3a5e7d2628f1e22ad711c017d459` against base `d679c13797c17caa9053da8e2e9e02636c5b9988`, werkrevisor 0.41.1.