Skip to content
cccskills
FreePublished on GitHub

test

Run or plan Yuzu's `/test` pre-commit and pre-push validation pipeline with quick, default, full, instructions, and quarantine modes. Use when the user says `/test`, `/test --quick`, `/test --full`, asks for the full test gate, or needs the Yuzu test-runs DB workflow.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md5.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Test

Use this skill for the high-level Yuzu validation pipeline. Route low-level build choices through $yuzu-build, Windows through $yuzu-windows-msvc, and Erlang caveats through the gateway guidance below.

Modes

  • default: build, upgrade test, live UAT, standard gates. About 30-45 minutes.
  • --quick: build plus offline C++ unit, EUnit, and Dialyzer. No live stack, no synthetic UAT.
  • --full: default plus OTA stubs/flows, sanitizer dispatch, coverage, and perf measurement. About 60-120 minutes.
  • --instructions: live-stack instruction definition suite only.
  • --instructions-quarantine: local quarantine ceremony only. Do not run on remote or SSH-only hosts.
  • --force-cleanup: clean this run's dangling containers before start.
  • --keep-stack: leave debug stacks running when the script supports it.

Run State

Every local /test pipeline run records gate results and timings in ~/.local/share/yuzu/test-runs.db, overrideable with YUZU_TEST_DB. Query with:

bash scripts/test/test-db-query.sh --latest
bash scripts/test/test-db-query.sh --last 5
bash scripts/test/test-db-query.sh --diff RUN_A RUN_B
bash scripts/test/test-db-query.sh --trend timing=phase7.perf
bash scripts/test/test-db-query.sh --flaky

The self-hosted CI pools also keep a persistent database per runner agent; they do not share one host-wide SQLite file:

  • Big Tam: /srv/ci/work-N/_tool/yuzu-test-runs/yuzu-bigtam-linux-N/test-runs.db
  • Wee Tam: D:\ci\test-runs\yuzu-weetam-windows-N\test-runs.db

ci.yml's Linux and Windows jobs initialize and write these databases automatically. Schema v3 preserves GitHub rerun attempts separately and stores job outcome/duration, platform, runner, commit/branch/event, ccache hit ratio, Meson suite result/duration/timeout, and recovered known-flake events. Query one on its host by setting YUZU_TEST_DB, for example:

YUZU_TEST_DB=/path/to/runner/test-runs.db \
  bash scripts/test/test-db-query.sh ci-stats --since 30d
YUZU_TEST_DB=/path/to/runner/test-runs.db \
  bash scripts/test/test-db-query.sh ci-suite-stats --since 30d
YUZU_TEST_DB=/path/to/runner/test-runs.db \
  bash scripts/test/test-db-query.sh ci-flakes --since 30d

Provision/repair paths are deploy/linux/Provision-BigTam-Runner-Telemetry.sh and deploy/windows/Provision-Windows-Runner.ps1. GitHub-hosted macOS runners are ephemeral and therefore cannot satisfy the runner-local persistence contract; their Meson logs remain Actions artifacts. ci-ingest is a coarse workflow-level backfill for older GitHub history, not a replacement for direct runner recording.

tests/known-flaky.json remains the reviewed allowlist. A listed case only passes CI if an isolated retry recovers; each recovery is also persisted in ci_flake_events so recurrence can be measured instead of inferred from logs.

Initialize each manual orchestration with a RUN_ID, TEST_DIR=/tmp/yuzu-test-$RUN_ID, LOG_DIR=$HOME/.local/share/yuzu/test-runs/$RUN_ID, COMMIT, BRANCH, and BUILDDIR=$(build_dir) from scripts/test/_portable.sh. Record gates with scripts/test/test-db-write.sh.

Phase Order

Wall-clock order is fixed:

  1. Phase 0 preflight: bash scripts/test/preflight.sh or --force-cleanup.
  2. Phase 1 build HEAD: Meson compile, Erlang rebar3 as prod release, and docker images except in quick mode.
  3. Phase 2 upgrade test: bash scripts/test/test-upgrade-stack.sh ...; skipped in quick mode.
  4. Phase 3 OTA: full mode only; may record SKIP if still stubbed.
  5. Phase 7a perf: full mode only, before UAT stack; measure-and-report only.
  6. Phase 4 fresh stack: bash scripts/start-UAT.sh; skipped in quick mode.
  7. Phase 5 gates: unit, EUnit, Dialyzer, CT, integration/e2e/synthetic UAT/puppeteer/instructions as applicable.
  8. Phase 6 sanitizers: full mode only, dispatched runner.
  9. Phase 7b coverage: full mode only, enforces tests/coverage-baseline.json.
  10. Phase 8 teardown and summary.

Phase 1 is mandatory-blocking. Other phases should normally continue so the operator gets one prioritized report.

UAT Lifetime Rule

Phase 8 must not stop the native UAT stack from scripts/start-UAT.sh. A successful default/full run intentionally leaves a working stack at tested HEAD for human inspection. Only stop it if the user explicitly asks.

Erlang Gateway Rules

  • Source scripts/ensure-erlang.sh before direct rebar3 work, then verify command -v erl.
  • For EUnit, use rebar3 eunit --dir apps/yuzu_gw/test; the --dir flag is mandatory.
  • Do not treat rebar3 eunit --module X as isolated; it runs after the full --dir phase in the same VM.
  • In parallel test fanout, use separate REBAR_BASE_DIR values for EUnit and CT to avoid _build races.
  • Always run Dialyzer after Erlang changes.

Perf Status

Perf is measure-only as of 2026-05-03. scripts/test/perf-gate.sh records metrics and exits PASS; humans inspect trend and distribution shape using the test-runs DB and docs/perf-baseline-calibration-2026-05-03.md.

Mode Shortcuts

For --quick, resolve the build directory and run only compile plus offline suites. Do not start UAT and do not invoke synthetic UAT.

For --instructions, use scripts/test/instructions-tests.sh after bringing up only the required live stack.

For --instructions-quarantine, use scripts/test/instructions-quarantine.sh only on a local machine where temporary self-disconnect is acceptable.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Run an adversarial two-phase code review of a change with TWO independent reviewers — Claude and Codex — who review alone, then cross-examine each other's findings, then Claude synthesizes a single weighted verdict. Use when the user says "/adversarial-review", "adversarial review", "review this with Codex", "get Codex to review", "two-reviewer review", "cross-examine this PR", or wants a second independent model to grade a change before merge.

The English summary is being prepared. Showing the original description.

DevNullLtd/Yuzu19Updated Oct 20, 2026

Authentication & Authorisation control plane for Yuzu — the canonical entry point for any work on RBAC, OIDC SSO, SAML, SCIM, MFA/TOTP, AD/Entra integration, API tokens, session lifecycle, enrollment, and the audit/evidence chain. Use when the user says "/auth-and-authz", "/auth", "/iam", asks to plan or implement an enterprise A&A feature, asks "what's our auth gap to enterprise readiness", asks to audit current auth state against SOC 2 CC6.x / Workstream B, or starts work that touches `auth_*`, `rbac_*`, `oidc_*`, `api_token_*`, `enrollment_*`, or `cert_store.*`. The skill bundles current-state inventory, required-features inventory, gap matrix, the canonical workflow for adding a new A&A feature, and the load order for the routed reference docs.

The English summary is being prepared. Showing the original description.

DevNullLtd/Yuzu19Updated Oct 20, 2026

Canonical patterns for caching in Yuzu CI workflows. Two snippets — one for ephemeral GHA-hosted runners (split actions/cache/restore + actions/cache/save, never `save-always: true`) and one for self-hosted runners (local filesystem cache under `runner.tool_cache`, no GHA cache round-trip). Use when adding a new vcpkg/ccache/dependency cache step to any workflow under `.github/workflows/`, or when reviewing a PR that touches `actions/cache@`.

The English summary is being prepared. Showing the original description.

DevNullLtd/Yuzu19Updated Oct 20, 2026

Review Yuzu C++ source changes for C++23 correctness, idiomatic standard-library use, ABI boundaries, threading primitives, and cross-compiler portability across GCC, Clang, MSVC, and Apple Clang. Use for any governance Gate 3 review when `.cpp`, `.hpp`, or `.h` files change.

The English summary is being prepared. Showing the original description.

DevNullLtd/Yuzu19Updated Oct 20, 2026

Review Yuzu C++ source changes for resource ownership, RAII, borrowed lifetimes, C ABI contexts, casts, process/syscall boundaries, callbacks, threads, and sanitizer coverage. Use for any governance Gate 3 review when C++ files change, paired with cpp-expert.

The English summary is being prepared. Showing the original description.

DevNullLtd/Yuzu19Updated Oct 20, 2026

Run the current session as a senior developer (Opus) leading a configurable junior fleet. Decomposes requests into scoped tasks, dispatches junior-developer subagents in parallel, optionally runs an architect plan-review gate before dispatch, autonomously resolves escalations, optionally dispatches a doc-writer second wave after juniors complete, then integrates and gates with /test + /governance. Use when the user says "/dev-team", "run the dev team", "delegate this to the juniors", "act as the senior dev", or wants a task built by a senior-led fleet.

The English summary is being prepared. Showing the original description.

DevNullLtd/Yuzu19Updated Oct 20, 2026

See all skills by DevNullLtd

Report a problem with this skill