القائمة
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.