---
name: ci-reports
description: >
  Fetch and read a GitLab pipeline's JUnit test report — the aggregated
  result of every `artifacts:reports:junit` in the pipeline. Surfaces the
  failing test cases (name, class, assertion message, stack trace) and per-test
  durations without scraping raw job logs. Use when the user says /ci-reports,
  'quels tests ont fail', 'quels tests ont échoué', 'le rapport de tests',
  'rapport de test', 'rapport de CI', 'rapport junit', 'test report', 'CI report',
  'montre les tests en échec', 'which tests failed', 'show the test report',
  or wants the structured test results of a pipeline. Also trigger for test timing
  and speed: 'accélère les tests', 'accélérer les tests', 'speed up the tests',
  'make the tests faster', 'mesure la durée des tests', 'durée des tests',
  'combien de temps prennent les tests', 'test duration', 'how long do the tests take',
  'les tests les plus lents', 'slowest tests', 'quels tests sont lents'.
argument-hint: "[pipeline URL or id]"
allowed-tools:
  - Read
  - Glob
  - Grep
  - Bash
  - Skill
---

Fetch a GitLab pipeline's JUnit test report and present the failing test cases — or, with `--slowest`, rank the tests by duration to guide test-suite speedups. This is the preferred entry point for diagnosing test failures and for measuring test timing — more reliable than scraping job logs.

## Required tools

- `glab`

Run `pysae-ai-tools tools require <tools>` before starting; if it exits non-zero, abort and report the install command from stderr to the user.

## How it works

All heavy lifting is handled by `pysae-ai-tools ci test-report` — it resolves the pipeline via `detect_context` (job/pipeline URL, MR, or CI env vars), calls the GitLab `test_report` API, and renders the failing cases. GitLab aggregates every `artifacts:reports:junit` of the pipeline into this report, so you get structured results regardless of the test framework (pytest, vitest, jest, rspec…).

## Read the test report

```bash
# Defaults to the detected pipeline; show only failures
pysae-ai-tools ci test-report

# Explicit pipeline (id or URL)
pysae-ai-tools ci test-report 123456
pysae-ai-tools ci test-report https://gitlab.com/grp/proj/-/pipelines/123456

# Structured output for further processing
pysae-ai-tools ci test-report --json

# Include passing/skipped cases too
pysae-ai-tools ci test-report --all
```

**Exit codes**: `0` = report present, no failures · `2` = report present with failures · `1` = no JUnit report published (or context unresolved). Treat `1` as "this pipeline has no test report" and tell the user; do not retry blindly.

**Output** (human): a summary line (`total · passed · failed · errors · skipped`) followed by each failing case as `[suite] classname › name` with the assertion message / stack trace indented underneath.

**Output** (`--json`): `{pipeline_id, total_count, success_count, failed_count, error_count, skipped_count, total_time, cases: [{suite, classname, name, status, execution_time, message}]}`.

## Measure test timing / speed up the suite

When the user wants to make the test suite faster, or asks how long tests take / which are slowest, rank the tests by duration:

```bash
# Top 20 slowest tests of the pipeline (any status), with per-test duration
pysae-ai-tools ci test-report --slowest 20

# Same, as JSON (cases sorted by execution_time desc) for further analysis
pysae-ai-tools ci test-report --slowest 20 --json
```

The summary line always reports the suite's `total_time`. Use the slowest list to point the user at the concrete tests worth optimising (or to `/code-profile` for a deeper profiler run on a specific slow test). Exit code is still `2` when the pipeline has failures, even in timing view — note any failures alongside the timing answer.

## Report to the user

- Summarise the counts, then list the failing tests with their `classname › name` and the assertion message.
- The `classname › name` selector is what you feed to a local reproduction command (`pytest <file>::<class>::<name>`, `vitest run <file> -t "<name>"`).
- If a test failure needs to be diagnosed and fixed, hand off to `/ci-debug` (which consumes this same command).
- If no JUnit report exists, say so and suggest `/ci-debug` (log-based analysis) or `/ci-artifacts` (raw artifact inspection) instead.

## Rules

- **French** for communication, English for commands
- **Never expose secrets** that might appear in a test's `system_output`/stack trace — mask tokens, passwords, API keys before displaying
- Do not parse `test_report` JSON by hand with `jq` — always go through `pysae-ai-tools ci test-report`

$ARGUMENTS
