Repository navigation
fix(ci): run the brakeman scan against the locked version - #25
developerz-ai[bot] merged 2 commits into
Conversation
bin/brakeman injected --ensure-latest, so brakeman aborted before scanning whenever upstream published a newer release: CI went red on a stale-but-valid lock and the scan never ran. The lock is a resolution, not a constraint. - bin/brakeman: drop the --ensure-latest injection, resolve the locked brakeman spec explicitly, report a newer upstream release on stderr at most (never fatal). Findings still fail the scan as before. - .github/dependabot.yml: exempt the dev-tools group from the 14-day cooldown (cooldown.exclude on the bundler entry) so brakeman/rubocop pins move within days; rails and the other groups keep the cooldown. - AGENTS.md, .dz/briefs/health.md: match the new cooldown behaviour. Dz-Task-Id: tsk_93d2c3e141069c96fc92d97bdd9df20f
Benchmarks: x86_64 (linux)
escape_bench (C ext) · peak RSS 120 MB
escape_bench (pure Ruby) · peak RSS 145 MB
render_bench (C ext) · peak RSS 132 MB
render_bench (pure Ruby) · peak RSS 132 MB
tag_bench (C ext) · peak RSS 39 MB
tag_bench (pure Ruby) · peak RSS 27 MB
Rails request (C ext) · peak RSS 241 MB
|
Benchmarks: aarch64 (linux)
escape_bench (C ext) · peak RSS 118 MB
escape_bench (pure Ruby) · peak RSS 150 MB
render_bench (C ext) · peak RSS 131 MB
render_bench (pure Ruby) · peak RSS 131 MB
tag_bench (C ext) · peak RSS 39 MB
tag_bench (pure Ruby) · peak RSS 26 MB
Rails request (C ext) · peak RSS 250 MB
|
✅ Reviewed — nothing blocking0 actionable comment(s) · grounded on your code ⏱ 1m 06s wall clock · 🤖 developerz.ai — automated review, running on your model and your box. |
There was a problem hiding this comment.
Review summary — 5 file(s), 2 finding(s).
Critical 0 · Major 0 · Minor 2 · Nit 0
Rewrites bin/brakeman to run the locked brakeman (drops --ensure-latest, warns on stderr about upstream skew), exempts dev-tools gems from the Dependabot cooldown, updates two docs, and adds a subprocess spec.
- concern-tests: nothing to review — The added specs exercise each changed bin/brakeman branch and assert its observable contract through the same subprocess seam as production, including failure paths; the documentation and Dependabot changes have matching configuration and no untested behavioural change requiring another finding.
🤖 developerz.ai review — automated, running on your model and your box. What is this? · Reviewed by router/MiniMax-M3 — 77.9k in / 823 out over 3 calls, on your flat-rate plan: no per-token charge (~$0.02 at list price).
|
Needs a human: sebyx07/ruby2html #25: checks are still failing and need you. CI is still failing after the platform spent its whole self-fix budget on this pull request. The failure survived every attempt — it needs you. 🤖 Posted by developerz.ai — an automated agent, not a human. |
|
Address review findings on #25
Work landed on #25 — watching it toward merge. 10m · 21 tool calls · 13 messages Sessions: coding run · review 1 🤖 developerz.ai, an automated agent, not a human — sebastian-3 (developerz-ai[bot]) · model |
Follow-up intent: Address review findings on #25 Dz-Task-Id: tsk_d333f1e37de10b15e179ca288112e5ac
There was a problem hiding this comment.
Review summary — 2 file(s), 0 finding(s).
Makes the upstream-version lookup opt-in via RUBY2HTML_CHECK_LATEST and reads the locked version from the bundle; both address the prior review threads. CI still runs the default path, so no network round trip.
🤖 developerz.ai review — automated, running on your model and your box. What is this? · Reviewed by router/glm-5.3-flash — 40.8k in / 425 out over 2 calls, on your flat-rate plan: no per-token charge (~<$0.01 at list price).
What
bin/brakeman injected --ensure-latest, so brakeman aborted before scanning
whenever upstream published a newer release: CI went red on a stale-but-valid
lock and the scan never ran. The lock is a resolution, not a constraint.
brakeman spec explicitly, report a newer upstream release on stderr at
most (never fatal). Findings still fail the scan as before.
cooldown (cooldown.exclude on the bundler entry) so brakeman/rubocop pins
move within days; rails and the other groups keep the cooldown.
Acceptance
grep -n ensure-latest bin/brakemanreturns nothing andbin/brakeman --no-pagerexits 0 with the locked brakeman.bin/brakeman --no-pagerin the test job; that step is unchanged by this diff.bin/rubocop bin/brakemanreports no offenses for the changed script.cooldown.default-days: 14but addscooldown.excludelisting the dev-tools group patterns ('rubocop*', 'brakeman', 'lefthook', 'rake*', 'benchmark-ips', 'capybara', 'faker', 'pry*'), so dev-tools bumps are proposed within days.ruby -ryaml -e 'YAML.safe_load_file(".github/dependabot.yml", aliases: true)'exits 0.Changes
bin/brakeman(edit) — Drop the--ensure-latestinjection (line 5): the scan must run against the brakeman locked in Gemfile.lock and never fail on version skew. Resolve the locked spec explicitly (Gem.loaded_specs['brakeman']) instead of Gem.bin_path, keep brakeman's default exit-on-warn so findings still fail, and report a newer upstream brakeman on stderr at most, never affecting the exit status. Comment why the flag must not come back..github/dependabot.yml(edit) — On the bundler entry keepcooldown.default-days: 14for everything else but exempt the dev-tools gems: addcooldown.excludewith the dev-tools group patterns ('rubocop*', 'brakeman', 'lefthook', 'rake*', 'benchmark-ips', 'capybara', 'faker', 'pry*') so their bumps are proposed within days, not two weeks. Dependabot has no per-group cooldown key, so exclude is the only lever. Update the header comment (line 9). Leave the other entries and the rails/other groups untouched.AGENTS.md(edit) — Line 124 (Maintenance model) claims Dependabot 'opens grouped weekly PRs after a 14-day cooldown'; that is no longer true for the dev-tools group. Reword that one cell so it matches the new .github/dependabot.yml (app dependencies wait 14 days, dev-tools are exempt). No other AGENTS.md change..dz/briefs/health.md(edit) — Line 12's health check says 'updates wait a 14-day cooldown before they open'; only app dependencies do now. Adjust that parenthetical so the check matches .github/dependabot.yml. No other change in the file.spec/bin/brakeman_spec.rb(create) — [test] The rewritten bin/brakeman adds untested paths (locked-gem resolution bin/brakeman:20-26, skew branch bin/brakeman:41-44, offline fallback bin/brakeman:9-13, aborts bin/brakeman:22,25): no spec fails if one is deleted. Add spec/bin/brakeman_spec.rb (run the script as a subprocess, like spec/bin/setup_spec.rb) pinning: a newer upstream version (stub Gem.latest_spec_for) is reported on stderr and never changes the exit status (not 5); findings still exit non-zero (brakeman's warnings code 3) and no --no-exit-on-warn is passed; the running brakeman is the locked one; no ensure-la [trimmed]Verification
./bin/checkpassed (exit 0) in 16s.What the editors ran to see the change working, and what they saw:
bin/rubocop bin/brakeman(brakeman): 1 file inspected, no offenses detected (exit 0)bin/brakeman --no-pager(brakeman): scan ran with the locked brakeman: 'Brakeman Version: 8.1.0', 'Checks Run: ...' 79 checks, 'Errors: 0', 'Security Warnings: 0'; process exit 0bin/brakeman --no-pager /tmp/bra_app (throwaway fixture: controller with 'render inline: params[:x]')(brakeman): 'Security Warnings: 1' and exit code 3 = brakeman's Warnings_Found_Exit_Code - findings still fail through bin/brakemanruby /tmp/fake_newer_brakeman.rb --no-pager (wrapper that stubs Gem.latest_spec_for to 99.0.0, then loads bin/brakeman)(brakeman): stderr: 'brakeman 8.1.0 is behind the latest release 99.0.0 - the scan ran against the locked version.'; stdout carried the normal report; exit status still 0 - the notice cannot change itgrep -n ensure-latest bin/brakeman ; grep -n exit-on-warn bin/brakeman(brakeman): both greps returned no match (exit 1) - no version-skew flag and no warning-flag override in the scriptruby -ryaml -e 'YAML.safe_load_file(".github/dependabot.yml", aliases: true); puts "yaml ok"'(deps): exit 0, stdout "yaml ok" — the file is still valid YAML after the cooldown.exclude addition.ruby -ryaml -e 'c = YAML.safe_load_file(".github/dependabot.yml", aliases: true)["updates"]; c.each { |u| puts "#{u["package-ecosystem"]} #{u["directory"]}: cooldown=#{u["cooldown"].inspect} groups=#{u["groups"]&.keys.inspect}" }'(deps): bundler /: cooldown={"default-days" => 14, "exclude" => ["rubocop*", "brakeman", "lefthook", "rake*", "benchmark-ips", "capybara", "faker", "pry*"]} groups=["rails", "dev-tools", "other"]; github-actions /: cooldown={"default-days" => 14}; devcontainers /: cooldown={"default-days" => 14}; docker /.devcontainer: cooldown={"default-days" => 14} — the 14-day cooldown survives on every entry, only bundler gained the exclude list, and the rails/dev-tools/other groups are untouched.code_changes on .github/dependabot.yml, AGENTS.md, .dz/briefs/health.md(deps): Diff is exactly three hunks: the dependabot header comment + bundler cooldown.exclude block, the AGENTS.md:124 Dependencies table cell, the .dz/briefs/health.md:12 table cell. The github-actions/devcontainers/docker entries and the rails/other group stanzas are byte-identical to before.code_grep -i 'cooldown|14-day|14 days' across the repo(deps): Only three files mention the cooldown: .github/dependabot.yml, AGENTS.md:124, .dz/briefs/health.md:12 — all three are the files this brief assigned, so no doc statement of the 14-day rule was left stale.ruby -ryaml -e 'YAML.safe_load_file(".github/dependabot.yml", aliases: true); puts "yaml ok"'(deps): yaml ok (exit 0) — the dependabot config still parses; the new cooldown.exclude list is well-formed YAMLNotes
Premises of the request the team disproved:
cooldown.default-days(.github/dependabot.yml:17-18); the dev-tools group stanza holds onlypatterns. Dependabot's schema has no per-group cooldown key (GitHub options reference: groups accept applies-to, dependency-type, exclude-patterns, group-by, [trimmed]run,check_latest(options[:ensure_latest])runs BEFORErun_report, so with bin/brakeman:5 injecting --ensure-latest today's CI exits with Not_Latest_Version_Exit_Code and the scan is skipped entirely - a skipped scan, not a red scan of the app.Part 1/2 of goal
rtk_610f3d7e29304704be95bf5a4ccd203f🤖 Opened by developerz.ai for task
tsk_93d2c3e141069c96fc92d97bdd9df20fon sebyx07/ruby2html.Raised automatically by the
raw_task_triagelane.