Pipeline-Check VS Code extension

Lint CI/CD pipelines for 22 providers against OWASP Top 10 CI/CD Risks and 14 other compliance frameworks. 810+ rules, inline in your editor: severity-graded gutter squiggles, hover descriptions with --explain prose, and recommended-action hints. Built on the same rule registry as the pipeline-check CLI, so editor findings match pipeline_check --output json byte-for-byte (modulo position translation).

Features

• Inline diagnostics — gutter squiggles + the Problems panel get a row per finding, severity-graded so CRITICAL and HIGH read red, MEDIUM yellow, LOW info-blue. Hover shows the rule title, the --explain prose, and a link to the rule documentation.
• Findings panel — dedicated slot in the activity bar with a Pipeline-Check pipeline glyph. Re-groups findings by severity (default), file, or rule via the title-bar Change Grouping button; activity-bar icon carries a live count badge.
• Status bar item — bottom-left of the window, shows the top two severity counts at a glance (e.g. 🛡 3C 1H). Click reveals the Findings panel.
• CodeLens summary — every scanned file carries a Pipeline-Check: 2 critical · 1 high lens at line 1. Click navigates to the Findings panel.
• Keyboard navigation — Alt+F8 / Shift+Alt+F8 jump between findings, with wrap at both ends. Mirrors VS Code's F8 for "next problem" so muscle memory carries over.
• Tunable signal — pipelineCheck.severityThreshold quiets the editor surface (low / medium / high / critical) without restarting the server; pipelineCheck.disabledProviders silences whole providers in a monorepo where Pipeline-Check would otherwise lint files belonging to a sub-project.

What it scans

Pilot provider coverage (single-file workflow providers plus Dockerfile):

Multi-file and context-heavy providers (Kubernetes, Helm, Terraform plans, live AWS, CloudFormation, SCM posture) ship in a later release; the CLI already covers them.

Install

Search for Pipeline-Check in the extensions panel, or install from the command line:

# Microsoft VS Code Marketplace
code --install-extension greylag-ci.pipeline-check

# Open VSX (VSCodium, Gitpod, code-server, Cursor)
codium --install-extension greylag-ci.pipeline-check

The extension is a thin LSP client; the rule engine itself runs in Python and must be installed separately:

python -m pip install "pipeline-check[lsp]"

Requirements

• VS Code 1.85 or newer.
• Python 3.11 or newer on PATH, with pipeline-check[lsp] installed.

Configuration

Commands and keybindings

All commands appear in the Command Palette under the Pipeline-Check category.

Workspace trust

Pipeline-Check spawns the configured Python interpreter to analyze workflow files. To keep that subprocess from running on first-open of a freshly-cloned repository, the extension declares capabilities.untrustedWorkspaces: "limited" — it stays inactive until the workspace is trusted. The serverCommand / serverArgs settings are machine-overridable, so a malicious .vscode/settings.json can't silently swap the interpreter or inject arbitrary args even after trust is granted.

Development

npm install
npm run compile           # typecheck + esbuild dev bundle
npm run watch             # bundle on change
npm test                  # vitest unit suite
npm run test:integration  # @vscode/test-electron — boots a real extension host
npm run smoke             # loads dist/extension.js with a vscode stub
npm run lint

Press F5 in VS Code with this folder open to launch an extension-host instance with the extension loaded. Two debug profiles ship in .vscode/launch.json:

• Run Extension: opens a fresh window with no workspace. Use this when iterating on the client wiring against a checkout of your own code.
• Run Extension (sample workflow): opens test-fixtures/sample-workflow/ as the workspace. The fixture is a deliberately-vulnerable GitHub Actions workflow and should produce four diagnostics (GHA-001, GHA-004, GHA-015, GHA-016) the moment you open the file. Quickest way to confirm the client → server round-trip works end-to-end.

Packaging

npm run package           # delegates to `vsce package`, produces pipeline-check-<version>.vsix

Releasing

Publishing is fully automated by .github/workflows/publish.yml. Tag a commit with vX.Y.Z matching package.json#version, push the tag, and the workflow packages the .vsix, publishes to both the VS Code Marketplace and Open VSX, and attaches the artifact to a GitHub Release with the matching CHANGELOG.md section as release notes.

git tag v0.1.2
git push origin v0.1.2

Tag-naming convention:

• vX.Y.Z → stable marketplace channel.
• vX.Y.Z-rc.N (or any version with a - after the semver core) → pre-release channel; the GitHub release is also marked prerelease.

Two repo secrets gate the publish jobs, both stored as environment secrets on the production GitHub Environment (required reviewer must approve before the publish steps run):

Every PR and every push to main is gated by .github/workflows/ci.yml running across [ubuntu-latest, windows-latest, macos-latest] with: lint, typecheck, unit tests (vitest), bundle smoke (loads dist/extension.js against a vscode stub to verify the package is loadable), npm audit --omit=dev --audit-level=high, vsce package, and on Linux the @vscode/test-electron integration suite. Release-day surprises stay rare.

┌──────────────────────┐     stdio JSON-RPC      ┌──────────────────────────┐
│ VS Code extension    │ ◀─────────────────────▶ │ pipeline_check.lsp        │
│ (TypeScript, this    │                          │ (Python, pygls; lives in  │
│  repo)               │                          │  dmartinochoa/pipeline-   │
│                      │                          │  check)                   │
└──────────────────────┘                          └──────────────────────────┘

Security

Report vulnerabilities privately via GitHub's Private vulnerability reporting — see SECURITY.md for the response SLA and threat model.

License

MIT.