Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(quality): visual regression of the apps' main journeys on every PR — screenshots of pages, not only components

Open
  • Is something wrong?
#375 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, playwright
Domain
ci-cd, testing

Research direction

Start by reading the shared workflow and helper requirements in this issue, then inspect the existing UI testing and baseline workflows it references, including krizaka-ui's update-baselines workflow. The work spans a reusable workflow, a helper package, journeys across three apps, documentation, and a blog issue; done means those journeys and first paint are compared on PRs, with reviewed baseline updates and documented diffs.

Written by the indexing model from the issue text.

Description

Founder decision (2026-10-28), after the question about Spartan (an Angular shadcn port — not for us): our component-level guards are at the market standard (Storybook baselines, axe ratchet, page-audit, ast-grep, size-limit, Sonar), but the pages of the apps are not compared visually. The small defects the founder sees (« Sign in » flash before the account mark, white boxes instead of post-its, empty maps) live there.

Goal: every PR of Yomizaka, Akinaza and orazaka-web-client compares screenshots of its main journeys against baselines, and fails on an unreviewed change.

  • Shared, one source: a reusable workflow in krizaka/.github + a small @krizaka/page-audit (or @krizaka/visual) helper — Playwright toHaveScreenshot, Linux container (same fonts as the baselines), « Update baselines » workflow on the branch like krizaka-ui's (never Docker locally).
  • The journeys, seeded with the one cast (.github#356, Éric · Mira · Camille): public landing, pricing, sign-in, signed-in home, the product's core screen (Yomizaka: a document report; Akinaza: a shop page, explore with the map, the booking; Orazaka: chat with a run) — desktop + phone, light + dark.
  • Also captured: the first paint (before hydration/queries) of a signed-in page, to catch flashes like krizaka-ui#827.
  • Stable: frozen clock, demo data, animations off (reduced motion), masked live values; flakiness counted in the test-efficacy KPIs (#357).
  • Baselines never committed as PR captures elsewhere; the diff images of a failing run are uploaded as workflow artifacts (and to Bunny pr-assets/ only when a PR body needs them).
  • Required check on main in the three apps once green for a week (strengthening protection only).
  • Documentation: how the UI tests work (layers: component baselines, page journeys, first paint, axe, page-audit), how to update baselines, how to read a failing diff — in the shared docs (krizaka/.github docs/standards) and linked from each app's README.
  • Then the blog post (krizaka-blog, technical, Oussama's voice, FR first then EN): our UI tests — what each layer catches, real examples (the « Sign in » flash, the empty map, the white flyers), what it costs, what is still not covered. Tracked in its own krizaka-blog issue.
Dominant language
No language data
Stars
0
Forks
0
Avg merge
1h 45m
Merged PRs (30d)
192

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from krizaka/.github

All issues in krizaka/.github

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.