菜单
How to read and contribute to the live test dashboard metrics. Load when updating metrics collection or interpreting dashboard data.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/projectbluefin/testsuite --skill dashboard-metrics命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Task → skill router and hard-rule set for projectbluefin/testsuite. Load this first in every session, then load only the sub-skills your task needs.
How to write behave scenarios and step definitions for the testsuite repo. Load when editing .feature files or steps.py.
How to call and debug the reusable testsuite e2e workflow. Load when changing e2e.yml, action inputs, or consumer-repo wiring.
基于 SOC 职业分类
正在显示 SKILL.md
| name | dashboard-metrics |
| version | 1.0 |
| last_updated | 2026-07-28 |
| id | dashboard-metrics |
| one_line_purpose | Read and extend the live testsuite dashboard metrics. |
| entry_point | docs/skills/ci-ops/dashboard-metrics/SKILL.md |
| category | ci-ops |
| mcp_compliance_level | partial |
| status | active |
| dependencies | [] |
| tags | ["dashboard","metrics","astro","telemetry"] |
| description | How to read and contribute to the live test dashboard metrics. Load when updating metrics collection or interpreting dashboard data. |
| metadata | {"type":"pattern","audience":"agents","maturity":"stable"} |
This skill guides agents through modifying, compiling, and deploying the QA dashboard located in dashboard/ and managing its serverless static-site data pipelines.
index.astro, run/[id].astro, headers, layouts, logs viewer)compile_data.py, convert_behave.py)publish-to-pages.yml)tests/** — use gnome.md or behave.mdprojectbluefin/lab repoe2e.yml) — use e2e-workflow.mdPath-Robust Script Design: When writing python aggregation or data conversion scripts under dashboard/scripts/, never hardcode relative string paths like ./raw-runs or ./src/data/. Execution directories differ between local development and CI runs. Always resolve path coordinates dynamically relative to the script's actual directory:
from pathlib import Path
SCRIPT_DIR = Path(__file__).resolve().parent
DASHBOARD_DIR = SCRIPT_DIR.parent
RUNS_DIR = DASHBOARD_DIR / "src" / "data" / "runs"
Build-Time Compilation Power: Take full advantage of Astro's build-time static generation. Instead of loading logs client-side at runtime, import raw run JSONs in the frontmatter of your Astro pages using Vite globbing:
const runFiles = import.meta.glob('../data/runs/*.json', { eager: });
runs = .(runFiles).( ({
: path.().().(, ),
...(content. || content)
}));
Compute aggregations, pass rates, trend lists, and top failing scenarios during the static build, resulting in instant load times for users.
Inline Script Bypasses: Astro typechecks <script> blocks by default. To prevent TypeScript compiler errors (such as Property 'style' does not exist on type 'Element') when writing standard client-side vanilla JavaScript, use the is:inline Astro directive:
<script is:inline>
// Vanilla JS runs verbatim on client-side with no strict TS compilation checks
document.querySelectorAll('.items').forEach(el => el.style.display = 'none');
</script>
Client-Side Telemetry Fetching: To integrate live, dynamic infrastructure status (like KubeVirt node states and active semaphore VM slots) that change rapidly, fetch the latest compiled JSON from raw GitHub Pages endpoints, and implement an offline-safe local fallback SEED dataset:
const TELEMETRY_URL = "https://raw.githubusercontent.com/projectbluefin/lab/main/docs/data/factory-stats.json";
async function getLiveTelemetry() {
try {
const res = await fetch(TELEMETRY_URL);
const stats = await res.json();
updateNodesDOM(stats);
} catch (e) {
console.warn("Fallback to offline dataset:", e);
}
}
Build-Time SSG Data Fetching (Astro Frontmatter): For high-performance landing page rendering with zero dynamic scraping lag, fetch external JSON datasets (like factory-stats.json or individual suite JSON files) during build time inside Astro's frontmatter blocks. This converts raw runtime REST fetching into statically pre-rendered HTML cards, tables, and charts:
// src/pages/index.astro
const statsRes = await fetch('https://projectbluefin.github.io/lab/data/factory-stats.json');
const stats = statsRes.ok ? await statsRes.json() : {};
Node-Based Markdown Skills Loader: Standard Astro Content Collections cannot access files located outside the dashboard's src/ folder (such as standard repository documentation in docs/skills or a sibling repository like ../common/docs/skills). Bypass this restriction by writing a dynamic build-time filesystem loader in src/utils/getSkills.js utilizing gray-matter for YAML parsing and marked for Markdown rendering.
Pagefind Search Indexing for Dynamically Loaded Skills: Enable Pagefind search on dynamically loaded Markdown files by adding data-pagefind-body directly on the <main> or <article> element containing the rendered skill body, and use Pagefind metadata selectors (such as data-pagefind-meta="category") to expose tags to the client-side search component.
Astro custom base URL constraints: The custom domain qa.projectbluefin.io is mapped to the root of the site. Therefore, when the custom domain is active, astro.config.mjs MUST keep base: '/' and site: 'https://qa.projectbluefin.io'. Do not change them to sub-paths.
Deploy CNAME Preservation: Deployment scripts that reset the gh-pages branch will wipe out the repository's CNAME setting, returning a 404 on the custom domain. The Pages deploy workflow must explicitly rewrite qa.projectbluefin.io to a CNAME file inside the deployment root on every run:
- name: Deploy Compiled Dashboard to gh-pages
run: |
cd old-gh-pages
find . -maxdepth 1 ! -name '.' ! -name '..' ! -name '.git' -exec rm -rf {} +
cp -r ../dashboard/dist/* .
touch .nojekyll
echo "qa.projectbluefin.io" > CNAME # MUST PRESERVE
git add . && git commit -m "Deploy Astro QA dashboard"
git push origin gh-pages
Tailwind v4 via @tailwindcss/vite (no Astro integration): The dashboard uses Tailwind CSS v4 through the official Vite plugin (@tailwindcss/vite), declared in astro.config.mjs under vite.plugins, plus @import "tailwindcss"; in src/styles/global.css (loaded via a <style is:global> block in src/layouts/Layout.astro). Custom design tokens live in the CSS @theme block in that file, not in a tailwind.config.* file — v4 is CSS-first, so config-file content globbing is gone. The deprecated @astrojs/tailwind integration (which capped astro at v5 via peer astro@"^3.0.0 || ^4.0.0 || ^5.0.0" and froze the vite/esbuild/sharp patch stream) must not be re-added. With the cap gone, renovate.json no longer constrains the astro major; validate any astro major bump locally with cd dashboard && rm -rf node_modules && npm ci && npm run build — npm install alone is not sufficient, because it resolves differently than npm ci.
publish-to-pages.yml is not exercised by PR checks: the workflow only triggers on schedule, workflow_dispatch, and pushes to main under dashboard/**. A dependency PR can therefore merge fully green and only break the dashboard hours later on the next 2-hourly cron. Any PR touching dashboard/package.json, dashboard/package-lock.json, or dashboard/scripts/** must be validated locally with npm ci && npm run build before merge.
| Rationalization | Reality |
|---|---|
"I will hardcode ./raw-runs in my script since I am running it from the root." | Someone else or the GHA run will execute it from another folder and fail with a directory mismatch. Always resolve paths relative to the script location. |
| "Astro should fetch all logs from a remote database in the browser." | Fetching hundreds of logs in client-side JS introduces major latency. Compiling them statically at build-time using import.meta.glob is faster and completely serverless. |
| "GitHub handles the custom domain automatically, no need to push CNAME." | Cleaning the pages branch during deploy deletes the CNAME file, which instantly breaks the custom domain. Always write CNAME back during the build. |
| "A dependency bump PR is green, so the dashboard still builds." | publish-to-pages.yml never runs on pull requests. Green PR checks say nothing about npm ci; run it locally before merging any dashboard/ dependency change. |
scripts/generate_badges.pyThe shields.io coverage badges are generated at publish time by parsing
.feature files under tests/*/features/. No counts are hardcoded, so the
badges always track current test content.
Every scenario lands in exactly one of three buckets, evaluated in this order:
@future or @pending@quarantine (at feature or scenario level)@pending counts as a stub, not as active. Both tags mean "written but not
running", and the badge already renders this bucket as N pending, so
excluding @pending inflated the active count and under-reported stubs.
Order matters: the stub check runs first, so a scenario tagged both @future
and @quarantine is reported as a stub. Adding a new "not running yet" tag
means updating count_scenarios() — otherwise those scenarios are silently
counted as active.
base: '/testsuite/' in astro.config.mjs while deploying to the custom domain qa.projectbluefin.io (breaks CSS andPagefind assets).<script is:inline> would safely bypass them.CNAME file inside the Pages deploy step, causing domain 404s on the next push.cd dashboard && npm run buildCNAME file generation is included in the publish-to-pages.yml file.