Skip to content

fix: message leak, dead report tests, gem packaging (3.0 readiness backlog) - #234

Merged
pftg merged 1 commit into
masterfrom
fix/v3ready-backlog-batch
Aug 23, 2026
Merged

fix: message leak, dead report tests, gem packaging (3.0 readiness backlog)#234
pftg merged 1 commit into
masterfrom
fix/v3ready-backlog-batch

Conversation

@pftg

@pftg pftg commented Aug 23, 2026

Copy link
Copy Markdown
Collaborator

Three independent backlog items from the beta2 review. No version/CHANGELOG changes — this line ships nothing until 3.0-readiness completes.

Baseline (mise x ruby@4.0.6 -- bundle exec): rake test:unit 522/0, rake test 555/0/6.
After: rake test:unit 523 runs, 0 failures, 0 skips · rake test 551 runs, 0 failures, 1 skip · standardrb clean (149 files, no offenses).


1. Vips::Image leaked into user-facing failure messages

Broken. ComparisonResult#to_h merged the whole meta hash, and the vips driver stores the raw diff mask image at meta[:diff_mask] (lib/snap_diff/drivers/vips_driver.rb:37). Reporters::Default#build_error_message JSON-dumps to_h, so a failing assertion printed:

({"area_size":100.0,"region":[20.0,15.0,30.0,25.0],"diff_mask":"#<Vips::Image:0x000000012f3c02a0>","difference_level":0.42})

#inspect was already clean (#214); #to_h was the remaining path.

Fix. #to_h excludes :diff_mask — it is an image object, not a metric, and the dedicated #diff_mask accessor still exposes it to programmatic consumers. to_h is not documented public API (nothing in docs/ references it; its only in-tree caller is the message builder), so no summarisation shim was added.

Red → green. Guard test test/unit/reporters/default_test.rb asserts the metrics line carries area_size / region / difference_level and contains neither Vips::Image nor 0x.

  • Red (fix reverted): Expected "({...,\"diff_mask\":\"#<Vips::Image:0x000000012b152468>\",...})\n" to not include "Vips::Image". — 1 runs, 1 failures
  • Green: 3 runs, 15 assertions, 0 failures

The assertion is scoped to message.lines.first because the tmpdir paths on the following lines contain a literal 0x.

chunky_png cross-check — its metadata is scalars only and never held a mask, so the message was already clean and is unchanged:

({"area_size":81,"region":[20,15,29,24],"max_color_distance":85.2})

2. Five HTML-report tests that never ran anywhere

Decision: delete them (option b). Rationale:

  1. They could never assert. test/integration/report_screenshot_test.rb:13 skipped unless RECORD_SCREENSHOTS — but in this repo that variable means record/refresh baselines, not verify. Everywhere else (browser_screenshot_test.rb, test_helper.rb:104) it is the flag that suppresses comparison. Gating the tests on it meant they only ran in the mode that overwrites the thing they would compare against.
  2. CI could not have asserted either. Baselines existed only under macos/cuprite/html_report; the only CI platform is linux, which has no html_report baselines at all. Wiring the env var into the full-ci job or the weekly cron would have bought real browser cost for a job that records five PNGs and passes unconditionally.
  3. Nothing consumed the output. No doc, README or fixture references report_both / report_heatmap / report_annotated_both.
  4. A rake conversion would duplicate what exists. rake report:sample (scripts/generate_sample_report.rb) already generates a sample HTML report and is wired into CI as the test-report-upload job. The deleted file re-implemented that generation and added browser captures on top.
  5. Real coverage is untouched. test/unit/reporters/html_reporter_test.rb has 18 tests over the HTML reporter — the surface refactor: default reporter, Comparison::Images, driver registry get SnapDiff homes (ADR-008 steps 4+5) #227/refactor: session surface and reporter registration get SnapDiff homes (ADR-008 step 6) #228 changed.

Deleted the test file and the five orphan macOS baselines.

Outcome check — no test is permanently skipped by an env var nobody sets. The only remaining env-gated skip is optional_test (test_helper.rb:107), and DISABLE_SKIP_TESTS: 1 is set in CI (.github/workflows/test.yml:83). Skip count drops 6 → 1 accordingly.


3. Packaging

Broken. The deny-list regex let gems.rb, Rakefile and capybara-screenshot-diff.gemspec into the gem (the gemspec is even named after gem A inside mirror gem B) while excluding README.md — leaving [← Back to README](../README.md) dead in 8 packaged doc pages.

Fix. Replaced the deny-list with an allow-list over git ls-files (still tracked-files-only, but fail-closed):

spec.files = `git ls-files -z`.split("\x0")
  .grep(%r{\A(lib/|docs/|README\.md\z|LICENSE\.txt\z|CHANGELOG\.md\z)})

Verified by building the gem before and after (gem buildGem::Package#spec.files), 97 → 94 files:

--- before.txt
+++ after.txt
@@
-CODE_OF_CONDUCT.md
@@
-Rakefile
-capybara-screenshot-diff.gemspec
+README.md
@@
-gems.rb

Unpacked after.gem top level is exactly CHANGELOG.md docs/ lib/ LICENSE.txt README.md; Rakefile, gems.rb and *.gemspec are absent.

Mirror gemspec (.github/workflows/release.yml:75-83) re-verified end to end — ran the workflow's own Gem::Specification.load → rename → to_ruby snippet and then gem build on the generated file: Successfully built RubyGem / Name: snap_diff-capybara / Version: 2.0.0.beta3, 94 files. The generated snap_diff-capybara.gemspec is untracked, so unlike before neither gemspec now ends up inside either gem.

Judgment calls worth a look: CODE_OF_CONDUCT.md also drops out (not linked from any packaged page), and docs/RELEASE_PREP.md still ships with docs/ — say the word and I will carve it out. README.md's link to CONTRIBUTING.md is dead inside the gem; left alone as a GitHub-facing pointer.

🤖 Generated with Claude Code

Summary by Sourcery

Clean up 3.0-readiness issues by sanitizing failure output, removing unusable report tests, and tightening gem contents.

Bug Fixes:

  • Prevent raw Vips::Image objects from leaking into user-facing comparison failure messages.
  • Correct gem packaging to include the README and exclude development files and gemspecs.

Enhancements:

  • Remove five non-functional HTML screenshot integration tests and their orphaned macOS baselines.

Build:

  • Replace the gem file deny-list with a fail-closed allow-list for runtime and shipped documentation files.

Tests:

  • Add coverage ensuring Vips-based failure messages expose metrics without image object internals.

…cklog)

Three independent beta2-review backlog items.

1. Vips::Image leaked into failure messages. ComparisonResult#to_h merged
   the whole meta hash, including the vips-only :diff_mask image object, so
   a failing assertion printed "diff_mask":"#<Vips::Image:0x...>". #to_h now
   excludes it; the object stays reachable via #diff_mask.

2. test/integration/report_screenshot_test.rb skipped all five tests unless
   RECORD_SCREENSHOTS -- the mode that records baselines rather than
   verifying them. Baselines existed only for macos/cuprite, so on the only
   CI platform (linux) there was nothing to compare against. Deleted, along
   with the orphan baselines. The HTML reporter keeps 18 unit tests, and
   `rake report:sample` already produces a sample report for eyeballing.

3. The gemspec shipped gems.rb, Rakefile and itself while omitting README.md,
   leaving a dead ../README.md link in the packaged docs. Replaced the
   deny-list regex with an allow-list: lib/, docs/, README, LICENSE, CHANGELOG.

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @pftg, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

@sourcery-ai

sourcery-ai Bot commented Aug 23, 2026

Copy link
Copy Markdown
Contributor

Reviewer's Guide

Fixes a leak of internal Vips::Image objects into user-facing failure messages, removes non-asserting HTML report screenshot tests and their macOS baselines, and tightens gem packaging to include only runtime code and docs while excluding build/dev artifacts.

Sequence diagram for sanitized comparison failure messages

sequenceDiagram
    participant VipsDriver
    participant ComparisonResult
    participant DefaultReporter
    participant User
    VipsDriver->>ComparisonResult: store diff_mask in meta
    DefaultReporter->>ComparisonResult: to_h
    ComparisonResult-->>DefaultReporter: metrics without diff_mask
    DefaultReporter->>User: build_error_message with JSON metrics
    User->>ComparisonResult: diff_mask
    ComparisonResult-->>User: raw image object
Loading

Flow diagram for fail-closed gem packaging

flowchart LR
    TrackedFiles[git ls-files] --> AllowList{Matches lib/ docs/ or packaged root docs?}
    AllowList -->|yes| Gem[Gem contents]
    AllowList -->|no| Excluded[Build and development files excluded]
Loading

File-Level Changes

Change Details Files
Prevent internal diff mask image objects from appearing in user-facing failure messages.
  • Changed ComparisonResult#to_h to build its hash from metrics only, excluding the :diff_mask entry from meta so it stays available only via #diff_mask accessor.
  • Added a unit test around Reporters::Default to assert the generated failure message’s metrics line includes area_size, region, difference_level and does not include Vips::Image or raw object hex addresses.
lib/snap_diff/comparison_result.rb
test/unit/reporters/default_test.rb
Remove unused HTML report screenshot integration tests and their platform-specific baselines that could never assert in CI.
  • Deleted the report_screenshot integration test file that was gated on RECORD_SCREENSHOTS and reimplemented sample report generation already covered elsewhere.
  • Removed the orphaned macOS-only HTML report baseline PNGs associated with the deleted tests.
  • Confirmed remaining env-gated tests are controllable via DISABLE_SKIP_TESTS and that overall skip counts drop as expected.
test/integration/report_screenshot_test.rb
macos/cuprite/html_report/*
Switch gem packaging from a regex-based deny-list to a git-tracked allow-list focused on runtime library code and documentation.
  • Replaced the gemspec files selection logic with a git ls-files allow-list, including lib/, docs/, README.md, LICENSE.txt, and CHANGELOG.md while excluding build/dev files like gems.rb, Rakefile, and the gemspec itself.
  • Verified before/after gem contents to ensure unwanted files are removed and required docs are present, including checking the mirror gemspec generation path used in the release workflow.
  • Accepted that CODE_OF_CONDUCT.md and CONTRIBUTING.md links are GitHub-facing and remain unshipped or dead inside the gem as a conscious trade-off.
capybara-screenshot-diff.gemspec
.github/workflows/release.yml

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@coderabbitai

coderabbitai Bot commented Aug 23, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@pftg, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 32 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: d3f655f2-4527-4647-88d4-673ff8190305

📥 Commits

Reviewing files that changed from the base of the PR and between 5f3fee6 and 5948fb1.

⛔ Files ignored due to path filters (5)
  • test/fixtures/app/doc/screenshots/macos/cuprite/html_report/report_annotated_both.png is excluded by !**/*.png
  • test/fixtures/app/doc/screenshots/macos/cuprite/html_report/report_base.png is excluded by !**/*.png
  • test/fixtures/app/doc/screenshots/macos/cuprite/html_report/report_both.png is excluded by !**/*.png
  • test/fixtures/app/doc/screenshots/macos/cuprite/html_report/report_heatmap.png is excluded by !**/*.png
  • test/fixtures/app/doc/screenshots/macos/cuprite/html_report/report_new.png is excluded by !**/*.png
📒 Files selected for processing (4)
  • capybara-screenshot-diff.gemspec
  • lib/snap_diff/comparison_result.rb
  • test/integration/report_screenshot_test.rb
  • test/unit/reporters/default_test.rb

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@pftg
pftg merged commit 7bf6d00 into master Aug 23, 2026
6 checks passed
@pftg
pftg deleted the fix/v3ready-backlog-batch branch August 23, 2026 09:02
pftg added a commit that referenced this pull request Aug 24, 2026
Second pass, from customer-persona findings. Each verified here before
acting; two of the four reported items turned out to be artifacts of the
PUBLISHED beta3 rather than of master, and are handled as such.

Baselines (the oldest bug in the tracker: #5 and #6 in 2018, #133 in 2024)
- README told users to "delete the baseline and re-run" in two places.
  It cannot work. `Vcs.checkout_vcs` (lib/snap_diff/vcs.rb:24) resolves
  every baseline with `git show HEAD:<path>`, and
  `ScreenshotMatcher#check_base_screenshot` calls it before
  `need_to_compare?` tests `base_path.exist?` -- so a committed baseline is
  fetched from HEAD no matter what the working tree says, and `rm` changes
  nothing.
- New first-class "Accepting an intentional change" section: the mechanism,
  the commit that actually accepts it, and the surprising part -- staging is
  not enough, so no local run goes green until you commit. The FAQ answer
  now says the same thing instead of the opposite.
- Deliberately does NOT document RECORD_SCREENSHOTS. It is printed by our
  own error message (screenshot_matcher.rb:73) but read nowhere in lib/;
  a separate lane is implementing it, and it should be documented once it
  works, not before.

Version pinning
- `gem "snap_diff-capybara"` unpinned installs 0.0.1 -- a placeholder whose
  entire payload is one README and zero Ruby files (verified by fetching and
  unpacking it), so the user gets an immediate LoadError. And unpinned
  `gem "capybara-screenshot-diff"` resolves to 1.15.1, not to the 2.0 the
  surrounding prose is selling. Every install instruction now pins, and the
  README says plainly that the mirror name is not the one to reach for.

CHANGELOG, all verified
- Failure messages leaked a libvips pointer struct via the comparison
  metadata; `to_h` excludes `diff_mask` since #234, which landed after the
  beta3 tag, so 2.0.0 final is the fix.
- Known limitation: fork-parallel runs write no HTML report. Workers
  accumulate assertions per process; the report is written from
  `Minitest.after_run` in the parent (integrations/minitest.rb:69), which
  never sees them. Artifacts and pass/fail are unaffected.
- A note for anyone sitting on a prerelease: beta3's deprecation channel was
  incomplete, so its silence is not evidence of being migrated.

Constants
- `Capybara::Screenshot::Os` -> `SnapDiff::Os` was in no rename table.

Gemspec
- rubygems_mfa_required. The four URI fields were added in the first commit.
pftg added a commit that referenced this pull request Aug 24, 2026
* docs: 2.0.0 release readiness

Audit of everything a 2.0.0 final would ship, and the fixes that did not
need lib/ changes.

CHANGELOG
- A v2.0.0 entry written for someone upgrading from 1.15.1, not a diff of
  the betas. What to change (the version), what they will see (exact
  warning text), the five things that can actually break, and what 2.1
  removes. Every claim verified against a real install; the beta sections
  stay as history.

Version consistency
- README, docs/UPGRADING.md: no more "beta"/"alpha"/"experiment" framing
  and no beta pins. Gemfile examples say `~> 2.0`.
- Gem name: `capybara-screenshot-diff` is the one we tell people to
  install; `snap_diff-capybara` is a reserved identical mirror. Stated
  once in the README with the dual-install consequence, applied
  everywhere else.
- Stale "3.0" references in the Rakefile and docs/architecture.md are now
  2.1 (#247 fixed the user docs and missed these).

Corrections to claims that were not true
- docs/drivers.md promised that everything 2.1 removes "warns once per
  process naming 2.1". `driver: :auto` is silent whenever ruby-vips is
  present, and the `driver:` setting itself never warns at all even
  though 2.1 deletes it (`NoMethodError`). Both are now written down as
  silent, in drivers.md and UPGRADING.md, since a note is the only notice
  they can get.
- README called ruby-vips "Optional". With neither ruby-vips nor
  chunky_png installed, comparisons raise
  `Wrong adapter nil. Available adapters: []`. Says so now.
- Setup examples no longer teach `driver: :vips`, a line users have to
  delete for 2.1.

Gem hygiene
- gemspec: summary/description that describe what the gem does, the
  rubygems metadata links (source, changelog, bug tracker, docs), and
  docs/docker-testing.md dropped from the package (it documents
  bin/dtest, which is not packaged). Dead bindir/executables removed --
  the allow-list never matched exe/.
- README's links to CONTRIBUTING.md and docker-testing.md are absolute,
  so they resolve from inside the gem too.
- test/unit/gemspec_packaging_test.rb pins the packaged file list: both
  Bundler.require entry files present (this broke twice), consumer docs
  in, contributor docs and build files out, capybara the only runtime
  dependency. Verified it fails when an entry file is unpackaged.
- *.gem is gitignored.

Release process
- The GitHub Release body linked to blob/main on a repo whose default
  branch is master -- 404 on every release so far. Links to the tag now.
- docs/RELEASE_PREP.md was a stale v1.15.1 checklist. It is now a runbook
  for how releases actually happen: what the workflow does step by step,
  the trusted-publisher prerequisite for BOTH gem names, prereleases,
  post-release verification, and what to do when a run fails halfway.
- CONTRIBUTING.md pointed at the wrong version.rb and recommended
  `rake release`, which publishes only one of the two gem names.

Verified with real installs on ruby 4.0.6: 1.15.1 -> this master via
path:, a canonical-names setup, `Bundler.require` under each gem name
from the built .gem, and the dual-install guard with both gems installed.

No lib/ changes. Version not bumped.

* docs: SnapDiff::Error is the base class for errors the gem defines, not every error it raises

docs/snapdiff.md's object map said "Base class for every error this gem
raises". It is not: a missing image backend raises a bare RuntimeError
("Wrong adapter nil. Available adapters: []", reproduced on a bundle with
neither ruby-vips nor chunky_png) and StableScreenshoter raises
ArgumentError. Verified the four defined errors -- ExpectationNotMet,
UnstableImage, WindowSizeMismatchError, DualInstallError -- do all inherit
SnapDiff::Error, so the useful half of the promise holds and is now the
one being made.

* docs: tag protection, not branch protection, is what gates the release tag push

Branch protection rules do not govern tag pushes; tag protection rules
(or rulesets) do. The runbook prerequisite now names the right control.

* docs: the per-screenshot driver: override dies quietly, the config setting dies loudly

Both were lumped together as "raises NoMethodError on 2.1". Only the config
setting does. Per-screenshot options are a free-form hash, so on 2.1
`screenshot "index", driver: :vips` is inert and nothing tells you the line
is dead -- #249's own upgrade note spells out the split. Grep-for-it advice
added, since that is the only signal a user gets.

* docs: pin versions, and stop telling people to delete baselines

Second pass, from customer-persona findings. Each verified here before
acting; two of the four reported items turned out to be artifacts of the
PUBLISHED beta3 rather than of master, and are handled as such.

Baselines (the oldest bug in the tracker: #5 and #6 in 2018, #133 in 2024)
- README told users to "delete the baseline and re-run" in two places.
  It cannot work. `Vcs.checkout_vcs` (lib/snap_diff/vcs.rb:24) resolves
  every baseline with `git show HEAD:<path>`, and
  `ScreenshotMatcher#check_base_screenshot` calls it before
  `need_to_compare?` tests `base_path.exist?` -- so a committed baseline is
  fetched from HEAD no matter what the working tree says, and `rm` changes
  nothing.
- New first-class "Accepting an intentional change" section: the mechanism,
  the commit that actually accepts it, and the surprising part -- staging is
  not enough, so no local run goes green until you commit. The FAQ answer
  now says the same thing instead of the opposite.
- Deliberately does NOT document RECORD_SCREENSHOTS. It is printed by our
  own error message (screenshot_matcher.rb:73) but read nowhere in lib/;
  a separate lane is implementing it, and it should be documented once it
  works, not before.

Version pinning
- `gem "snap_diff-capybara"` unpinned installs 0.0.1 -- a placeholder whose
  entire payload is one README and zero Ruby files (verified by fetching and
  unpacking it), so the user gets an immediate LoadError. And unpinned
  `gem "capybara-screenshot-diff"` resolves to 1.15.1, not to the 2.0 the
  surrounding prose is selling. Every install instruction now pins, and the
  README says plainly that the mirror name is not the one to reach for.

CHANGELOG, all verified
- Failure messages leaked a libvips pointer struct via the comparison
  metadata; `to_h` excludes `diff_mask` since #234, which landed after the
  beta3 tag, so 2.0.0 final is the fix.
- Known limitation: fork-parallel runs write no HTML report. Workers
  accumulate assertions per process; the report is written from
  `Minitest.after_run` in the parent (integrations/minitest.rb:69), which
  never sees them. Artifacts and pass/fail are unaffected.
- A note for anyone sitting on a prerelease: beta3's deprecation channel was
  incomplete, so its silence is not evidence of being migrated.

Constants
- `Capybara::Screenshot::Os` -> `SnapDiff::Os` was in no rename table.

Gemspec
- rubygems_mfa_required. The four URI fields were added in the first commit.

* docs: stop teaching two commands that do not work

Two customer personas independently followed the docs and got a green bar
on a page they had deliberately broken.

`rake test` does not run `test/system/` in a Rails app. The Quick Start
told users to run it, so step 1 produced `0 runs` and no baselines --
which reads as a pass. The example is a Rails system test; the command
now matches it, with a callout, because "0 runs" is the single easiest
way to believe visual testing is working when nothing is running.

`RECORD_SCREENSHOTS=1` appeared in three user-facing docs for a feature
that has never existed in `lib/` -- it is this repository's own test-suite
convention, read by `test/test_helper.rb`. The user-facing copies are
replaced with the flow that actually works: run the suite, which rewrites
every changed baseline in place, then `git add` and commit. The
contributor page keeps it and now says plainly that it is not a library
feature.

* docs: make the Quick Start something a new user can actually run

A reviewer built a stock Rails 8.1 app, ran the documented Quick Start
end to end, and none of it worked. Fixes, each verified against a scratch
app or against lib/:

- `gem "capybara-screenshot-diff", "~> 2.0"` does not resolve. rubygems
  has 1.15.1 and 2.0.0.alpha1..beta3 and no final 2.x, and Bundler never
  picks a prerelease from a plain requirement, so `bundle install` fails
  with `Could not find gem 'capybara-screenshot-diff (~> 2.0)'`. All five
  install snippets now pin `2.0.0.beta3` and say why. RELEASE_PREP gains
  the step that swaps them back to `~> 2.0` as part of the 2.0.0 push,
  so the good pin lands with the release rather than before it.

- The Quick Start taught the API 2.1 deletes, silently. `require
  "capybara_screenshot_diff/minitest"` + `include
  CapybaraScreenshotDiff::Minitest::Assertions` print nothing: they are
  eager aliases, so `const_missing` never fires. The Quick Start now
  starts on canonical `SnapDiff`, and README/CHANGELOG/snapdiff.md say
  which doors actually warn (config accessors, `include`,
  `default_options`, `const_missing`) and which cannot.

- The CI "Record new baselines" job could not record a new baseline.
  `check_base_screenshot` runs before `capture_screenshot` and
  `fail_if_new` is true whenever `ENV["CI"]` is set, so a new screenshot
  raises before anything is written and the commit step finds nothing.
  The job now clears `CI` for that step.

- `bundle exec rake test` / `rails test` swept out of the three CI
  workflows, "The Short Version", and the historical upgrade sections:
  in a Rails app they skip `test/system/` and report `0 runs`.

- The delete-the-baselines block in UPGRADING replaced with the commit
  workflow the README documents.

- `docs/drivers.md` told you to delete the `driver:` setting on one
  screen and to add it on another; same for configuration.md,
  migration-guide.md.

- `rescue SnapDiff::Error` does not catch a failed assertion under the
  framework integrations -- Minitest converts it to `Minitest::Assertion`
  and RSpec to `ExpectationNotMetError`. Said so.

- "2.0 will not rewrite a baseline you already committed" contradicted
  the README and reality: a failing run does rewrite the baseline path.
  Reworded to what is meant (no re-encoding) plus what actually happens.

Also, all verified in a scratch app: the `git add
test/fixtures/screenshots/` path was never the default (`doc/screenshots`
is); the example failure output showed a `max_color_distance` key the
vips path never emits; the artifact table listed three of five files;
`application_system_test_case.rb` omitted both `require "test_helper"`
and `driven_by` (without the latter the same page captures at 2800x1610
instead of 1400x1257); `homepage_test.rb` omitted `require
"application_system_test_case"` and raised NameError as printed; and
`DEBUG=1` never had anything to do with keeping `.diff.png` files.

Docs only. rake test:unit 610/0, standardrb clean.

* docs: three residuals from the verifier pass

- bug_report template told reporters to run `rake test`, which runs zero
  system tests in a Rails app -- the same trap this branch exists to remove.
- drivers.md said an unknown per-screenshot `driver:` key is "simply inert".
  It is validated and raises; only the deprecation warning is absent.
- drivers.md said `:auto` and `:chunky_png` each warn once per process.
  `:auto` is silent when ruby-vips resolves; only `:chunky_png` warns.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant