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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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