Context
Themes and client-facing repos need Lighthouse CI checks on PRs to gate a11y scores and performance budgets.
This should be a reusable workflow so every consuming repo gets a consistent setup.
See apermo/idea-pool#31 for the broader a11y testing initiative.
Proposal
Create a new reusable-lhci.yml workflow with inputs:
url or urls — the page(s) to audit (e.g. the DDEV site URL)
a11y-threshold — minimum a11y score (default: 90)
performance-threshold — minimum performance score (optional)
config-path — optional path to a .lighthouserc.js in the consuming repo
The workflow should:
- Set up the environment (Node, Chrome)
- Run
@lhci/cli against the target URL(s)
- Report results as a PR status check
- Upload the HTML report as a workflow artifact
Open questions
- Does the consuming repo need a running DDEV site, or can LHCI start its own server?
For themes, the e2e workflow already boots DDEV — could LHCI piggyback on that, or should it be independent?
- Artifact retention policy for Lighthouse reports
Context
Themes and client-facing repos need Lighthouse CI checks on PRs to gate a11y scores and performance budgets.
This should be a reusable workflow so every consuming repo gets a consistent setup.
See apermo/idea-pool#31 for the broader a11y testing initiative.
Proposal
Create a new
reusable-lhci.ymlworkflow with inputs:urlorurls— the page(s) to audit (e.g. the DDEV site URL)a11y-threshold— minimum a11y score (default: 90)performance-threshold— minimum performance score (optional)config-path— optional path to a.lighthouserc.jsin the consuming repoThe workflow should:
@lhci/cliagainst the target URL(s)Open questions
For themes, the e2e workflow already boots DDEV — could LHCI piggyback on that, or should it be independent?