playwright-test-results

作者: microsoft

從彙總的 DuckDB 資料庫查詢 Playwright CI 測試結果。回答關於不穩定測試、失敗率、緩慢測試以及每次執行/SHA/PR 的問題…

npx skills add https://github.com/microsoft/playwright --skill playwright-test-results

Playwright Test Results (DuckDB)

A single DuckDB file holds recent Playwright CI test results, so you can answer questions about failures, flakiness, and slow tests with plain SQL. It is refreshed every few hours.

Get the database

Download the latest snapshot:

npm ci                       # first time only, from the repo root
GITHUB_TOKEN=$(gh auth token) node utils/test-results-db/cli.ts download

The snapshot may be missing the newest runs. To top it up locally, run update:

GITHUB_TOKEN=$(gh auth token) node utils/test-results-db/cli.ts update --lookback-days 3

Query it through the bundled @duckdb/node-api binding — no separate DuckDB install needed, it ships in node_modules after npm ci:

node --input-type=module -e '
import { DuckDBInstance } from "@duckdb/node-api";
const conn = await (await DuckDBInstance.create("utils/test-results-db/test-results.duckdb")).connect();
console.table((await conn.runAndReadAll(process.argv[1])).getRowObjectsJson());
' "SELECT count(*) FROM test_results"

Integer columns come back as strings (JSON-safe), so do ranking and filtering in SQL, not in JS.

Schema

Single table test_results, one row per test result (one row per retry). The columns are inferred from the parquet the reporter emits (tests/config/parquetReporter.ts), plus two trailing columns this CLI adds:

ColumnMeaning
run_id, run_attemptGitHub Actions run identity
run_started_atwhen the run started
workflow_namee.g. tests 1 / tests 2 / tests others / MCP
eventpush / pull_request
head_sha, head_branch, pr_numberwhat was tested
bot_namee.g. chromium-ubuntu-22.04-node20, webkit-macos-15-large — the CI bot. OS and arch are encoded here; there is no separate os column.
project_nameCI project = browser + suite, e.g. chromium-page, webkit-library, playwright-test
test_titletitle path within the file, joined by › (describe › test)
file, line, column_numbersource location (file is relative to repo root)
expected_statuspassed / skipped / ...
statusactual result: passed / failed / timedOut / skipped / interrupted
retry0 = first attempt
result_started_atwhen this attempt started
duration_msresult duration
error_messageall errors joined, ANSI-stripped (NULL when none)
tagslist of strings, e.g. ['@slow', '@flaky'] (use list functions / list_contains)
annotationslist of {type, description} structs, e.g. [{'type': 'skip', 'description': 'flaky on CI'}] (empty list when none)
artifact_idthe GitHub artifact this row came from (dedupe key)
ingested_atdebug only — when this row was imported

Notes:

  • A test is identified by (project_name, file, test_title) — group on that tuple. (Playwright's test_id hash is deliberately not stored; those three columns are its pre-image.)
  • Flakiness is derived, not stored. The signal that matters most is cross-run: a test whose final verdict (after retries) flips between runs — green in some, red in others. A separate within-run flake is a test a retry rescued inside a single run (failed→passed).
  • Real failures vs intentional ones: filter expected_status = 'passed'. Tests marked test.fail() record status='failed' with expected_status='failed' and would otherwise dominate any "most failing" list.
  • The db is size-capped by run count: the oldest whole runs are evicted over time, so it holds a recent window, not full history.

Example queries

Group tests by (project_name, file, test_title) and (for failure/flakiness) scope to expected_status = 'passed' so intentional test.fail() tests don't skew the results.

Flaky across runs — the test's final verdict flips between runs (this is what makes a red CI run ambiguous). least(failed_runs, passed_runs) ranks genuinely bimodal tests above both always-broken and one-off failures:

WITH per_run AS (
  SELECT project_name, file, test_title, run_id, run_attempt,
         arg_max(status, retry) AS final_status,
         any_value(expected_status) AS expected
  FROM test_results
  GROUP BY project_name, file, test_title, run_id, run_attempt)
SELECT project_name, test_title,
       count(*) AS runs,
       count(*) FILTER (WHERE final_status IN ('failed','timedOut')) AS failed_runs,
       count(*) FILTER (WHERE final_status = 'passed') AS passed_runs,
       round(100.0 * count(*) FILTER (WHERE final_status IN ('failed','timedOut'))
             / count(*), 1) AS fail_pct
FROM per_run
WHERE expected = 'passed'
GROUP BY project_name, test_title
HAVING failed_runs > 0 AND passed_runs > 0 AND runs >= 10
ORDER BY least(failed_runs, passed_runs) DESC, failed_runs DESC
LIMIT 20;

Filter by tag (tags is a list, not a string):

SELECT project_name, test_title, count(*) AS runs
FROM test_results
WHERE list_contains(tags, '@slow')
GROUP BY project_name, test_title
ORDER BY runs DESC
LIMIT 20;

Generate a linked emoji run history

For a compact result that drops straight into a GitHub comment, render each final run verdict as a linked square. Edit the four test identity fields, then run:

node --input-type=module <<'EOF'
import { DuckDBInstance } from "@duckdb/node-api";

const repository = "microsoft/playwright";
const test = {
  projectName: "firefox-library",
  file: "library/proxy.spec.ts",
  testTitle: "should exclude patterns",
  botName: "firefox-macos-15-large",
};

const conn = await (await DuckDBInstance.create(
  "utils/test-results-db/test-results.duckdb"
)).connect();
const result = await conn.runAndReadAll(`
  WITH per_run AS (
    SELECT run_id, run_attempt,
           any_value(run_started_at) AS run_started_at,
           arg_max(status, retry) AS final_status,
           arg_max(expected_status, retry) AS expected_status,
           list(status ORDER BY retry) AS attempt_statuses
    FROM test_results
    WHERE project_name = $projectName
      AND file = $file
      AND test_title = $testTitle
      AND bot_name = $botName
    GROUP BY run_id, run_attempt
  )
  SELECT run_id, run_attempt, final_status, attempt_statuses
  FROM per_run
  WHERE expected_status = 'passed'
    AND final_status IN ('passed', 'failed', 'timedOut')
  ORDER BY run_started_at, run_id, run_attempt
`, test);

const markdown = result.getRowObjectsJson().map(row => {
  const rescued = row.final_status === "passed" &&
    row.attempt_statuses.some(status => status === "failed" || status === "timedOut");
  const emoji = rescued ? "🟧" : row.final_status === "passed" ? "🟩" : "🟥";
  const url = `https://github.com/${repository}/actions/runs/${row.run_id}/attempts/${row.run_attempt}`;
  return `[${emoji}](${url})`;
}).join("");

console.log(markdown);
EOF

The output is Markdown:

[🟩](https://github.com/microsoft/playwright/actions/runs/123/attempts/1)[🟧](https://github.com/microsoft/playwright/actions/runs/456/attempts/1)[🟥](https://github.com/microsoft/playwright/actions/runs/789/attempts/1)

Each square is one workflow run attempt, oldest first. Green means passed, orange means a retry rescued an earlier failure, and red means failed or timed out. arg_max(status, retry) picks the final verdict after retries, while grouping by (run_id, run_attempt) keeps retries from turning into extra squares. The /attempts/<n> URL links to the exact rerun that produced the result.

Fetching the full detail

The db stores per-result summaries. For the full step tree / attachments / stdio, fetch the original blob report for that run, if the run uploaded one. A row identifies it by run_id + bot_name: the run's blob artifact is named blob-report-<bot_name>.

# List the run's blob artifacts and find the one for this bot_name:
gh api /repos/microsoft/playwright/actions/runs/<run_id>/artifacts \
  --jq '.artifacts[] | select(.name | startswith("blob-report")) | {id, name}'

# Download it (name == "blob-report-<bot_name>"):
gh api /repos/microsoft/playwright/actions/artifacts/<artifact_id>/zip > blob.zip

Blob and parquet artifacts have a 7-day retention, so this works only for recent runs; the db itself retains summaries longer (until run-count eviction).

來自 microsoft 的更多技能

oss-growth
microsoft
開源增長駭客角色
agent-framework-azure-ai-py
microsoft
使用Microsoft Agent Framework Python SDK(agent-framework-azure-ai)构建Azure AI Foundry代理。适用于使用AzureAIAgentsProvider创建持久化代理、使用托管工具(代码解释器、文件搜索、网络搜索)、集成MCP服务器、管理对话线程或实现流式响应。涵盖函数工具、结构化输出和多工具代理。
development
airunway-aks-setup
microsoft
在AKS上設定AI Runway——從裸叢集到執行模型。涵蓋叢集驗證、控制器安裝、GPU評估、供應商設定及首次部署。時機:「設定AI Runway」、「上線AKS叢集」、「安裝AI Runway」、「airunway設定」、「部署模型至AKS」、「在AKS上進行GPU推論」、「在AKS上設定KAITO」、「在AKS上執行LLM」、「在AKS上使用vLLM」、「在AKS上設定模型服務」、「AI Runway控制器」。
devops
appinsights-instrumentation
microsoft
使用Azure Application Insights檢測Web應用程式的指南。提供遙測模式、SDK設定與組態參考。適用時機:如何檢測應用程式、App Insights SDK、遙測模式、什麼是App Insights、Application Insights指南、檢測範例、APM最佳實踐。
devops
applicationinsights-web-ts
microsoft
使用Application Insights JavaScript SDK(@microsoft/applicationinsights-web)為瀏覽器/Web應用程式進行檢測。適用於真實使用者監控(RUM)——頁面檢視、點擊、AJAX/fetch依賴、例外、自訂事件,以及與後端OpenTelemetry追蹤關聯的瀏覽器端GenAI代理追蹤。涵蓋SDK載入器指令碼與npm設定、框架擴充(React、React Native、Angular)、點擊分析、遙測初始化器,以及從瀏覽器發出的代理/工具/模型span的OTel GenAI語意慣例。
devops
azure-ai-anomalydetector-java
microsoft
使用適用於 Java 的 Azure AI 異常偵測器 SDK 建置異常偵測應用程式。在實作單變量/多變量異常偵測、時間序列分析或 AI 驅動監控時使用。
development
azure-ai-language-conversations-py
microsoft
使用 azure-ai-language-conversations Python SDK 實作對話語言理解(CLU)。當使用 ConversationAnalysisClient 分析對話意圖與實體、建置 NLP 功能,或將語言理解整合至應用程式時使用。
development
azure-ai-ml-py
microsoft
Azure Machine Learning SDK v2 for Python。用於機器學習工作區、作業、模型、資料集、計算資源與管線。 觸發詞:「azure-ai-ml」、「MLClient」、「workspace」、「model registry」、「training jobs」、「datasets」。
development