Skip to content

test: cover MetricsDashboard's single-point Sparkline arm end to end - #1093

Merged
castrojo merged 1 commit into
mainfrom
quality/metrics-sparkline-single-point-e2e
Oct 6, 2026
Merged

castrojo merged 1 commit into
mainfrom
quality/metrics-sparkline-single-point-e2e

Conversation

@hivecommons-hive

Copy link
Copy Markdown
Contributor

Test Improvement

Covers the values.length === 1 ? 50 arm of the x-coordinate ternary in
Sparkline (src/components/MetricsDashboard/index.js line 28) — the arm that
centres a lone data point, because the expression beside it divides by
values.length - 1 and would be a division by zero.

No shape in the checked-in data reaches it. data/metrics.json defines exactly
two lifecycle trends: submissions carries zero values, so Sparkline returns
No trend data yet before reaching the ternary at all, and publications
carries five, which takes the arm beside it.

Why the variant build

tests/e2e/fixtures/data/** overlays are additive — the extra record renders
alongside the real ones and nothing already covered stops rendering. Appending
a point to submissions in the ordinary coverage build is not additive in that
sense: submissions is the only trend that reaches the empty-values arm, so
giving it a point would trade that arm for this one rather than add a case.

The point is appended in tests/e2e/fixtures/data-variants/metrics.json
instead, the mechanism tests/e2e/data-variants.spec.js already documents for
this class of branch. One Playwright run then visits /metrics and
/e2e-coverage-variant/metrics and the report unions what each build reached,
so both arms end up covered.

What this adds

  • tests/e2e/fixtures/data-variants/metrics.json — one appended point on
    referenceArchitectureLifecycle.trends.submissions.values, beside the
    existing generatedAt clearing. The overlay's append path must already
    exist in the real file, so a regenerated data/metrics.json that drops the
    trend fails the build rather than silently losing the coverage.
  • tests/e2e/metrics-sparkline-variant.spec.js — two cases, skipped outside
    E2E_COVERAGE=1. The real route asserts the premise (one trend empty, none
    single-point, No trend data yet rendered); the variant route asserts the
    lone point is centred. Both read the trends through loadSiteData() rather
    than hard-coding a label or a number, so an edited overlay fails here instead
    of leaving a test that asserts nothing. The variant case also asserts the
    other trend still has more than one point, so the variant does not quietly
    trade one uncovered region for another.

No change to any file under src/.

Evidence

  • E2E, before — CI artifact e2e-coverage id 11348560988, run
    37317061554,
    job End-to-end coverage, main at 8afaa67 (this branch's base):
    {"file":"src/components/MetricsDashboard/index.js","regions":44,"coveredRegions":38,"regionPercent":86.36,"uncoveredRegions":[28,65,76,85,124,174]}.

  • Rendered output, after — npm run build:e2e:coverage:variant at this
    branch's head, then reading the two built pages. Inside
    section[aria-labelledby="lifecycle-title"]:

    build No trend data yet sparkline labels polyline points
    build/metrics (real) present Trend from 2024-11 to 2026-07 0,4 25,… 100,…
    build/e2e-coverage-variant/metrics absent Trend from 2026-01 to 2026-01, Trend from 2024-11 to 2026-07 50,4, 0,4 25,… 100,…

    points="50,4" is the arm under test: a single pair, x at the centre of the
    0 0 100 24 viewBox rather than an index-derived offset. It is what the new
    spec asserts, computed from the overlaid value rather than written as a
    literal.

  • npm run test:unit:coverage:check exits 0 — the overlay change leaves
    tests/e2e-data-fixtures.test.mjs passing, including
    the variant build clears the fields the ordinary build keeps, since
    generatedAt is still cleared to null.

  • npx prettier --check clean on both changed files.

  • npx playwright test --list collects both cases.

Playwright itself was not run locally: this environment has no root and
chrome-headless-shell cannot load libglib-2.0.so.0, so the browser will not
launch here. The assertions were instead verified against the SSR markup of the
two builds above, which is the same DOM the hydrated page asserts on. CI's
End-to-end coverage job is the authority on the resulting region count.

Related Issue

Closes #1092

Coordination

Touches exactly two files — tests/e2e/fixtures/data-variants/metrics.json and
the new tests/e2e/metrics-sparkline-variant.spec.js — and one function under
test, Sparkline in src/components/MetricsDashboard/index.js.

Disjoint from every open hold-gated PR. In particular it does not edit
tests/e2e/data-variants.spec.js or tests/e2e-data-fixtures.test.mjs, where
#1034 and #1078 are working, which is why the cases live in a new spec file
rather than beside the existing variant-build cases; #1034's variant overlay is
community-people.json, a different file in the same directory. It does not
touch tests/e2e/data-fixtures.spec.js (#1054), the e2e reporter cluster
(#1040, #1070), tests/svg-active-content.test.mjs (#1088, #1090),
scripts/fetch-community-people.mjs (#1085), or the component specs #1058,
#1060, #1065, #1075, #1081, #1083.

The --check-source-regions floor in .github/workflows/ci.yml is not
re-derived here: this change only raises the covered-region count, so the
existing floor still holds, and that path cannot be pushed by this lane in any
case.

— hive: agent=quality backend=copilot model=claude-opus-5 copilot=1.0.88

src/components/MetricsDashboard/index.js line 28 centres a lone sparkline
point with the 'values.length === 1 ? 50' arm of its x-coordinate ternary,
because the expression beside it divides by values.length - 1. The arm had
no end-to-end coverage and no shape in the checked-in data reaches it:
data/metrics.json defines exactly two lifecycle trends, submissions with
zero values (which returns 'No trend data yet' before the ternary) and
publications with five (which takes the other arm).

Appending a point to submissions in the ordinary coverage build would not
add a case -- submissions is the only trend that reaches the empty-values
arm, so it would trade that arm for this one. The point is appended in the
variant build instead, the mechanism tests/e2e/data-variants.spec.js
documents for exactly this class of branch, so one Playwright run reaches
both arms and the report unions them.

Closes #1092

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: quality <quality@hive.kubestellar.io>
@hivecommons-hive hivecommons-hive Bot added the hold label Oct 5, 2026
@hivecommons-hive

Copy link
Copy Markdown
Contributor Author

Important

Held for human review by the hive's ACMM level gate.

This PR was opened by the "quality" agent while Hive policy required a human checkpoint for that agent. Non-outreach agents are held at ACMM L3–L5; the outreach agent is always held because it publishes project-facing communication.

Hive will keep the hold label until a human removes it. Operators can make a deliberate one-off release during an ACMM level change with release_level_holds=true, but level changes never release this hold automatically.

@hivecommons-hive

Copy link
Copy Markdown
Contributor Author

CI note: runs 37363814397 (Validate repository) and 37363814525 (CodeQL) on the current head (bd7842d) report failure, but no step actually failed: the cancelled jobs are the non-required End-to-end coverage job (cancelled ~15 min in, 19:30→19:45Z) and CodeQL's Analyze JavaScript. Lint, Validate, and End-to-end tests all passed. No replacement run is queued. Same cancellation pattern as #1090 (run 37338929390).

The agent tier cannot re-run jobs (gh run rerun is not allowlisted), so this needs a maintainer: gh run rerun 37363814525 --repo cncf/endusers --failed (and 37363814397) from the Actions UI or CLI. No branch push is needed or appropriate — the diff is not implicated.


🐝 Hive Agent: ci-maintainer | Instance: hosted-available-lke648397-260827-5n31 | SHA: unknown

— hive: agent=ci-maintainer backend=copilot model=kimi-k3 copilot=1.0.88

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[quality] MetricsDashboard's single-point Sparkline arm (line 28) has no end-to-end coverage

1 participant