ci: nothing checks images/og-card.jpg still matches build-og-card.mjs
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 50/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- github-actions, javascript, nodejs
- Domain
- build-system, ci-cd
Research direction
Read scripts/build-og-card.mjs, render.yml, css.yml, and the related #171 discussion; first run npm run og-card and compare the generated image with images/og-card.jpg. Settle whether byte-exact or perceptual comparison is reliable on CI, then wire the check into the workflow. Done means CI detects a stale committed JPEG without flaky results.
Written by the indexing model from the issue text.
Description
Split out of the #168 review.
assets/css/main.css is generated-and-committed, and css.yml runs npm run css:check so the committed output can't go stale. images/og-card.jpg is generated-and-committed the same way by scripts/build-og-card.mjs, and nothing checks it at all — the script's own header says so:
Not part of CI, and nothing checks the committed JPEG still matches this source: run it by hand after changing the headshot or the wording, and commit the result alongside.
So editing NAME, DOMAIN, ROLES or the card's CSS and forgetting npm run og-card leaves the site shipping the old card, and the only signal is someone looking at a LinkedIn preview. The same edit silently desynchronises og:image:alt, which names the roles the card prints.
This is checkable: during the #168 review, npm run og-card reproduced the committed images/og-card.jpg byte for byte (md5 17932ab290c6e059a50d7a79e56ecabe), so a css:check-style hook is viable in principle:
"og-card:check": "npm run og-card && git diff --exit-code -- images/og-card.jpg"
Two things to settle before wiring it up:
- Is byte-exactness reproducible off this machine? It was stable across four local runs, but it depends on the Chrome build's text rasterisation and on libvips/mozjpeg versions. If a CI runner's Chrome differs, a byte comparison will flap. A perceptual comparison (decode both, compare mean absolute difference under a threshold) would be robust where a byte check isn't.
- Where it runs. It needs Chrome and it writes into the repo tree, so it fits
render.yml(which already has Chrome) better than a pre-commit hook.
Related: #171 tracks sharing the headless-Chrome plumbing between check-render.mjs and build-og-card.mjs; doing that first would make this cheaper.
- Dominant language
- HTML
- Stars
- 0
- Forks
- 0
- Avg merge
- 8h 17m
- Merged PRs (30d)
- 58
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from laywill/laywill.github.io
-
design
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
laywill/laywill.github.io#186 ·
-
design
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
laywill/laywill.github.io#183 · 1 comment ·
-
Difficulty 2/5 Half a day Newbie friendliness 74/100
laywill/laywill.github.io#135 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
laywill/laywill.github.io#106 ·
-
infra needs-william
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
laywill/laywill.github.io#35 · 1 comment ·
All issues in laywill/laywill.github.io
Similar issues
-
status: needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
conda-forge/spacy-feedstock#177 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
area:jail bug security severity:low track:open-source
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
micro-ROS/micro_ros_setup#837 ·