currents-integration
Wires Currents.dev cross-run test analytics into a Playwright suite: installs `@currents/playwright`, authors `currents.config.ts` (env-sourced `recordKey` + `projectId`), registers `currentsReporter()`, enables trace/video/screenshot artifacts, and runs via `npx pwc` so per-test traces stream to the Currents dashboard with over-time flakiness, slowest-test, and pass-rate trends. Use when a Playwright suite needs hosted cross-run suite-health analytics; for a static per-run report use extentreports or allure-reports, and to sync results into TestRail / Xray / Zephyr test management use test-management-sync.
Install with skills.sh (any agent)
npx skills add testland/qa --skill currents-integrationcurrents-integration
Overview
Per currents-docs (opens in new window):
"Playwright reports explain a single run. Currents explains your test suite over time, and more."
Currents.dev is a SaaS test analytics platform that ingests per-run results via runner-specific reporters and provides longitudinal views (flake rate over time, slowest-test trends, PR-level deltas). It's commonly paired with Playwright and Cypress.
This skill covers the Playwright integration; the Cypress integration follows the same shape with @currents/cypress (see references/ci-and-cypress-integration.md).
When to use
If the suite is small (<50 tests) and the team only needs the per-run report, Playwright's built-in HTML reporter is enough - no SaaS dependency.
How to use
Install
Per currents-pw-quickstart (opens in new window):
npm i -D @currents/playwright
# Equivalent for pnpm / yarn / bun.Configure currents.config.ts
Place next to playwright.config.ts. Per currents-pw-quickstart (opens in new window):
import { CurrentsConfig } from "@currents/playwright";
const config: CurrentsConfig = {
recordKey: process.env.CURRENTS_RECORD_KEY!,
projectId: "your project id goes here",
};
export default config;The recordKey is the project's record-write secret - never check it into the repo. The projectId is non-secret (visible in the Currents dashboard URL); it's safe to inline.
Register the reporter
In playwright.config.ts, per currents-pw-quickstart (opens in new window):
import { defineConfig } from "@playwright/test";
import { currentsReporter } from "@currents/playwright";
export default defineConfig({
reporter: [currentsReporter()],
// ... other config ...
});The reporter forwards every test event (start, finish, attachments) to the Currents API.
Enable artifacts
Per currents-pw-quickstart (opens in new window), the use section should enable the three artifact types Currents consumes:
use: {
trace: "on",
video: "on",
screenshot: "on",
}The defaults Playwright ships with (trace: "on-first-retry") cap the artifact volume; Currents wants every test's trace to drive its analytics. For a high-volume suite, consider trace: "retain-on-failure" as a middle ground.
Run
Per currents-pw-quickstart (opens in new window):
# Reads recordKey from env, projectId from config:
npx pwc
# Or pass on the CLI:
npx pwc --key XXX --project-id YYYpwc is the Currents-aware Playwright wrapper. It runs Playwright with the Currents reporter active and streams results in real-time; on completion, it prints a dashboard URL.
Worked example
A 120-test Playwright suite, first Currents run:
import { CurrentsConfig } from "@currents/playwright";
const config: CurrentsConfig = {
recordKey: process.env.CURRENTS_RECORD_KEY!,
projectId: "abc123def",
};
export default config;reporter: [currentsReporter()],
use: { trace: "on", video: "on", screenshot: "on" },export CURRENTS_RECORD_KEY=... # from the Currents dashboard
npx pwcpwc streams each test event to Currents and prints a dashboard URL on completion. After the second run on main, the dashboard's trend graphs start showing flake rate and slowest-test movement across runs.
Operating in CI
Run npx pwc from the CI job with CURRENTS_RECORD_KEY supplied as a secret, and trigger on both push to main and pull_request so the dashboard has a baseline (main) to compare each PR run against. Keep Playwright's HTML report as an if: always() artifact fallback for when the dashboard is unreachable. The full GitHub Actions workflow, the per-PR-vs-main baseline rationale, and the Cypress sister integration are in references/ci-and-cypress-integration.md.
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
Hardcoding recordKey in currents.config.ts | Secret leaks into git; bad actors can pollute the dashboard. | Read from env (see Configure currents.config.ts). |
Running both Playwright's default HTML reporter and currentsReporter without artifact handling | Doubled artifact size; CI runner disk pressure. | Keep both reporters; rely on the if: always() upload (see Operating in CI). |
| Sending production / staging real-user CI runs to Currents | Mixes test signal with monitoring signal; analytics pollute. | Send only test runs; production observability lives elsewhere. |
Disabling trace: "on" to "save space" | Currents's value is per-test trace inspection; disabled traces gut the analytics. | Use retain-on-failure as a middle ground (see Enable artifacts). |
| Recording PR runs without recording main runs | No baseline; per-PR diff is meaningless. | Record main on every push too (see Operating in CI). |
Treating pwc's exit code as gate-only | The dashboard surfaces flake / regression context the CI exit code hides. | Read both: pass/fail from CI; flake / regression from the dashboard or its API. |
Limitations
References
Currents CI wiring and the Cypress integration
View source (opens in new window)Currents CI wiring and the Cypress integration
Deep reference for the currents-integration SKILL.md. Consult when wiring Currents into GitHub Actions, coordinating per-PR vs main baselines, or setting up the Cypress sister integration.
CI integration
# .github/workflows/e2e.yml
name: e2e
on:
pull_request:
push:
branches: [main]
jobs:
e2e:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v4
with: { node-version: '20' }
- run: npm ci
- run: npx playwright install --with-deps
- name: Run tests with Currents
env:
CURRENTS_RECORD_KEY: ${{ secrets.CURRENTS_RECORD_KEY }}
run: npx pwc
- name: Upload Playwright HTML report (fallback)
if: always()
uses: actions/upload-artifact@v4
with:
name: playwright-report
path: playwright-report/
retention-days: 7if: always() on the artifact upload preserves the local report even when the Currents stream succeeds - useful when the dashboard is unreachable.
Per-PR vs main runs
The Currents dashboard separates main runs (baseline) from PR runs (comparison). For the analytics to make sense:
Set the CI workflow's branch + PR triggers (the CI integration example above) to record both.
Cypress shape (sister integration, same pattern)
The Cypress integration follows the same shape with @currents/cypress instead of @currents/playwright:
npm i -D @currents/cypressThen in cypress.config.ts:
import { defineConfig } from 'cypress';
import { currentsConfig } from '@currents/cypress';
export default defineConfig({
...currentsConfig({
recordKey: process.env.CURRENTS_RECORD_KEY!,
projectId: 'your-project-id',
}),
});Run via npx cypress-cloud run (the Cypress equivalent of pwc).
Related skills
allure-reports
Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to the sunset ExtentReports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.
coverage-diff-reporter
Builds a per-PR coverage delta report from any pair of LCOV / Cobertura / JSON coverage outputs (current run + baseline from the merge target) - emits a per-file table with line% / branch% deltas, called-out new files, hidden drops (overall +0.1pp but one file -8pp), and a single-line PR-comment summary. Use when the team has coverage in CI but needs human-readable PR feedback that points at the specific file the reviewer should focus on, not just an aggregate number.
coverage-py-analysis
Configures coverage.py for Python projects - wires `coverage run` (replacing `python` for instrumentation), enables branch coverage via the `--branch` flag or `branch = True` config, manages the `.coverage` data file (single-process and `combine` for parallel pytest-xdist runs), authors `.coveragerc` with `source` / `omit` / `fail_under`, and emits the format the downstream tool needs (`coverage report` for terminal, `coverage xml` for Cobertura, `coverage html` for human review, `coverage lcov` for SaaS, `coverage json` for programmatic post-processing). Use for any Python test stack (pytest, unittest, nose) that needs PR-time coverage signal.
jacoco-analysis
Configures JaCoCo for JVM projects (Java / Kotlin / Scala / Groovy) - wires the runtime agent via `jacoco-maven-plugin` `prepare-agent`, generates per-build reports (HTML / XML / CSV) via the `report` goal, gates the build via the `check` goal with element / limit / minimum rules, parses the six native counters (instructions, branches, lines, methods, classes, cyclomatic complexity), and converts JaCoCo XML to LCOV / Cobertura when downstream tools need a different format. Use when the JVM build is Maven / Gradle and the team wants the canonical JVM coverage tool - or to convert JaCoCo output for cross-language coverage aggregation.
junit-xml-analysis
Explains CI test numbers that disagree with what the suite actually did - a 'slowest tests' list dominated by the wrong suite, a release gate or dashboard reading only the summary attributes on the suite element and never the cases below them, or a pass rate that quietly counts skipped tests as passes. Parses JUnit-format XML (the interchange format Jenkins, GitHub Actions, GitLab, Buildkite, and CircleCI all ingest) into per-suite and per-case metrics tables - passed / failed / errored / skipped, time, classname, message, stack - groups failures by classname for trend analysis, and separates new failures from flakes by cross-referencing the `flakyFailure` and rerun elements. Use when a report, gate, or metric derived from test results cannot be trusted.
lcov-analysis
Parses both mainstream coverage interchange formats: LCOV `.info` text files (produced by gcov, llvm-cov, Coverage.py via `py2lcov`, JaCoCo via `xml2lcov`, Devel::Cover, Jest via `lcov` reporter, NYC, and most others) and Cobertura XML (coverage-04.dtd - emitted by JaCoCo, coverage.py `--xml`, Jest's `cobertura` reporter, coverlet, gocover-cobertura; full parser in references/cobertura.md). Extracts per-file line / function / branch metrics from the canonical record keywords (TN/SF/FN/FNDA/FNF/FNH/BRDA/BRF/BRH/DA/LH/LF), computes the diff vs a baseline, and emits per-file gating verdicts. Use for PR coverage gates that don't depend on a specific language runtime, whichever of the two formats the CI emits.
test-coverage-targeter
Builds a "what to test next" recommendation by combining a coverage report (LCOV / Cobertura / coverage.py JSON / Jest JSON / JaCoCo XML) with the PR's `git diff`, ranking uncovered branches by risk × cost - risk weighted by McCabe cyclomatic complexity and code-churn frequency, cost weighted by the unit-test pyramid layer (unit tests cheaper than integration than E2E). Also carries the coverage debt ledger: a weekly per-file drift report over N historical main runs flagging `falling` (line% slid >M pp from peak), `stale` (flat coverage + high churn), and `orphan` (lost last covering test) files, whose rows feed the same targeting. Emits a prioritized list with concrete file:line targets and the test layer recommended for each. Use when a team has the budget to write 5 - 10 new tests and needs help picking which uncovered code to target first instead of blindly chasing 100% coverage, or when specific modules are eroding silently while whole-repo coverage looks fine.
test-management-sync
Syncs automated test results into test management tools - TestRail (standalone, `add_run` + batched `add_results_for_cases`), Xray for Jira (JWT auth + `/api/v2/import/execution/*`), and Zephyr Scale (Bearer token + `/testexecutions`) - from CI. The body carries the vendor-independent push-results workflow (map tests to case IDs, open a run / execution / cycle per build, batch results back, close on main only, run as an `if: always()` step) with TestRail as the worked example; full vendor specifics live in references/ (testrail.md, xray.md, zephyr.md). Use when automated suites must keep the team's test management view in sync without a human copy-paste step; for hosted cross-run flakiness analytics rather than TCM sync use currents-integration, and for authoring / migrating test CASES rather than pushing results see qa-test-management's tcm-case-management.
test-run-summary-author
Build-an-X workflow that turns a structured test-run artifact (JUnit XML, Allure JSON, TestRail / Xray / Zephyr export) plus optional release context (version, build URL, deploy target) into a narrative markdown summary for release notes, an exec status update, or a stand-up Slack post. Distinct from the per-framework parsers junit-xml-analysis / allure-reports / coverage-diff-reporter, which emit structured tabular reports: this skill takes the same data and writes the human-readable narrative. Use when a manager needs a draft release note or stand-up summary from a single run; for cross-run trend analytics use currents-integration.