Skip to content

No Pester job in CI: production PowerShell under scripts/vscode has zero CI coverage #562

Description

@drmoisan

Summary

.github/workflows/ci.yml runs five jobs: actionlint, format-check, build-analyzers,
build-nullable, and mstest-coverage. None of them executes Pester. The repository's production
PowerShell under scripts/vscode/ therefore has no CI coverage of any kind.

Impact

The build-ci-coverage-gate-fidelity epic delivered its core logic as four PowerShell scripts:

  • scripts/vscode/Invoke-MSTestWithCoverage.ClosureFilter.ps1 (+389)
  • scripts/vscode/Invoke-MSTestWithCoverage.Helpers.ps1 (+151/-17)
  • scripts/vscode/Invoke-VSBuild.ps1 (+13/-3)
  • scripts/vscode/Invoke-MSTestWithCoverage.ps1 (+1)

with 751 lines of accompanying Pester tests. No required status check executes any of it. A
regression in the coverage arithmetic or the closure filter would merge green.

The only signal on the epic's integration head was a local run: 70/70 Pester tests passed across
five containers. That is recorded at
docs/features/epics/build-ci-coverage-gate-fidelity/evidence/qa-gates/pester-integrated-tree.2026-08-15T05-10.md.

Suggested resolution

Add a reusable workflow _pester.yml following the _<name>.yml convention documented in
.github/workflows/README.md, call it from ci.yml, and add its check-run name to the main
ruleset's required contexts.

Two known obstacles for whoever picks this up:

  1. tests/scripts/vscode/Invoke-VSBuild.Tests.ps1 dot-sources the script's entire top-level body in
    BeforeAll, so a test run invokes vswhere.exe and executes Sync-PackageReferences.ps1, which
    writes .csproj files. This is environment-dependent and makes measured coverage
    non-deterministic (observed 53/84 on one run against 71/84 in committed evidence for the same 84
    analyzed lines). It needs an injectable seam before it can run on a clean runner.
  2. Repository-wide PowerShell line coverage currently measures about 68.9-71.5%, below the 85% floor
    in .claude/rules/general-unit-test.md. The shortfall is concentrated in five never-tested
    scripts, not in the epic's changed lines (100% covered). A CI Pester gate would need either those
    scripts tested or an explicit, recorded threshold decision.

Found during the build-ci-coverage-gate-fidelity epic fan-in review.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions