greylag-ci/pipeline-check-vscode

# Pipeline-Check VS Code 扩展 [](https://github.com/greylag-ci/pipeline-check-vscode/actions/workflows/ci.yml) [](https://github.com/greylag-ci/pipeline-check-vscode/actions/workflows/codeql.yml) [](https://marketplace.visualstudio.com/items?itemName=greylag-ci.pipeline-check) [](https://open-vsx.org/extension/greylag-ci/pipeline-check) [](https://marketplace.visualstudio.com/items?itemName=greylag-ci.pipeline-check) [](https://socket.dev/openvsx/package/greylag-ci.pipeline-check/overview) [](LICENSE) [](https://coderabbit.ai) 基于 OWASP Top 10 CI/CD 风险及另外 14 种合规框架，对 22 种提供商的 CI/CD 流水线进行代码检查。超过 810 条规则，直接在您的编辑器内工作：按严重程度分级的边栏波浪线、带有 `--explain` 详细说明的悬停描述以及建议操作提示。基于与 [pipeline-check](https://github.com/dmartinochoa/pipeline-check) CLI 相同的规则注册表构建，因此编辑器中的发现结果与 `pipeline_check --output json` 的输出逐字节匹配（位置转换除外）。     ## 功能 - **内联诊断** — 边栏波浪线 + “问题”面板中的每个发现结果单独一行，按严重程度分级，因此“严重”和“高”显示为红色，“中”为黄色，“低”和“信息”为蓝色。悬停会显示规则标题、`--explain` 说明以及指向规则文档的链接。 - **发现结果面板** — 活动栏中带有 Pipeline-Check 流水线图标的专用插槽。通过标题栏的**更改分组**按钮，可按**严重程度**（默认）、**文件**或**规则**对发现结果进行重新分组；活动栏图标带有实时计数徽章。 - **按面板严重程度筛选** — 标题栏的**显示/隐藏严重程度**按钮可让您在仅处理“严重”问题时静音“中”等级别，而无需更改编辑器全局的 `severityThreshold` 设置。状态按工作区持久化。 - **快速修复灯泡** — 每个发现结果都带有一个灯泡，提供**打开 `<规则ID>` 文档**、**复制规则 ID** 和**在发现结果面板中显示**选项 — 便于分类处理，无需在面板间来回切换。 - **状态栏项** — 窗口左下角，一眼即可查看最高两级的严重程度计数（例如 `🛡 3C 1H`）。工具提示包含引擎版本，以便您了解哪个 `pipeline_check` 安装正在与编辑器通信。单击可打开发现结果面板。 - **CodeLens 摘要** — 每个扫描的文件在第 1 行都带有 `Pipeline-Check: 2 critical · 1 high` 的 CodeLens。单击可导航至发现结果面板。 - **键盘导航** — `Alt+F8` / `Shift+Alt+F8` 在发现结果之间跳转，并在两端循环。镜像了 VS Code 的 `F8`（“下一个问题”），便于肌肉记忆迁移。 - **可调信号** — `pipelineCheck.severityThreshold` 可静音编辑器界面（`low` / `medium` / `high` / `critical`），无需重启服务器；`pipelineCheck.disabledProviders` 可在单体仓库中静音整个提供商，避免 Pipeline-Check 对属于子项目的文件进行检查。 - **快速失败引擎检查** — 当 LSP 导入 Python 引擎失败时，扩展会立即显示安装/升级操作，而不是等待 30 秒的启动上限。对于低于扩展最低要求版本的引擎，会显示专门的**在终端中升级**提示。 ## 扫描范围 试点提供商覆盖范围（单文件工作流提供商加 Dockerfile）： | 提供商 | 触发文件 | |---|---| | GitHub Actions | `.github/workflows/*.yml` | | GitLab CI | `.gitlab-ci.yml` | | Azure DevOps | `azure-pipelines.yml` | | Bitbucket Pipelines | `bitbucket-pipelines.yml` | | CircleCI | `.circleci/config.yml` | | Google Cloud Build | `cloudbuild.yaml` | | Buildkite | `.buildkite/pipeline.yml` | | Drone CI | `.drone.yml` / `.drone.yaml` | | Jenkins | `Jenkinsfile`（声明式和脚本式） | | Dockerfile | `Dockerfile` / `Containerfile` | 多文件和上下文密集型提供商（Kubernetes, Helm, Terraform 计划, 实时 AWS, CloudFormation, SCM 状态）将在后续版本中发布；CLI 已涵盖它们。 ## 安装 Pipeline-Check 分为**两部分**，通过 stdio 相互通信： 1. **Python 规则引擎** — 检查器本身，从 PyPI 安装。 2. **VS Code 扩展** — 一个轻量级 LSP 客户端（本仓库），负责生成引擎并在编辑器中显示其发现结果。 两者缺一不可。扩展本身不进行扫描；如果未安装引擎，发现结果面板会显示一个**在终端中安装**按钮，为您运行以下命令。 ### 1. 安装 Python 引擎 需要 `PATH` 中有 Python 3.11+： ``` python -m pip install "pipeline-check[lsp]" ``` 如果 `pipeline_check` 位于虚拟环境或 `python3`（而非 `python`）下，请将 [`pipelineCheck.serverCommand`](#configuration) 指向解释器的绝对路径。 ### 2. 安装扩展 需要 VS Code 1.85+。在扩展面板中搜索 `Pipeline-Check`，或通过命令行安装： ``` # chnical terms in English. code --install-extension greylag-ci.pipeline-check # For "Microsoft VS Code Marketplace": codium --install-extension greylag-ci.pipeline-check ``` ### 3. 验证 打开任何支持的配置文件（参见[扫描范围](#what-it-scans)）——发现结果会在一两秒内内联显示，状态栏会显示 `🛡` 计数。如果您看到的是 `🛡 LSP not ready`，请从命令面板运行 **Pipeline-Check: Show language server output**；最常见的原因是 `serverCommand` 指向的解释器未安装 `pipeline_check`。 ## 配置 | 设置项 | 默认值 | 描述 | |---|---|---| | `pipelineCheck.serverCommand` | `python` | 用于启动语言服务器的命令。如果 `pipeline_check` 安装在其他解释器下，请覆盖此项。标记为 `machine-overridable`：工作区覆盖需要明确提示。 | | `pipelineCheck.serverArgs` | `["-m", "pipeline_check.lsp"]` | 传递给服务器命令的参数。标记为 `machine-overridable`，原因相同。 | | `pipelineCheck.severityThreshold` | `low` | 产生诊断的最低严重程度。取值范围为 `low`, `medium`, `high`, `critical`。镜像 CLI 的 `--severity-threshold`。 | | `pipelineCheck.disabledProviders` | `[]` | 要完全静音的提供商 ID。与被禁用提供商路径匹配的文件诊断信息将在到达编辑器前被丢弃。取值范围为 `github-actions`, `gitlab`, `azure`, `bitbucket`, `circleci`, `cloud-build`, `buildkite`, `drone`, `jenkins`, `dockerfile`（也涵盖 Containerfile）。 | | `pipelineCheck.trace.server` | `off` | 跟踪 LSP 流量。调试时设置为 `verbose`。 | ## 命令与快捷键 所有命令都可在命令面板的 **Pipeline-Check** 类别下找到。 | 命令 | 默认快捷键 | |---|---| | **重启语言服务器** — 终止并重新生成 LSP 进程 | | | **显示语言服务器输出** — 聚焦输出通道（LSP 服务器日志 + `[client]` 客户端侧面包屑） | | | **在终端中安装 LSP 服务器** — 打开一个终端，已键入但未执行 `pip install` 命令 | | | **在终端中升级 LSP 服务器** — 对于过时引擎，流程相同但使用 `pip install --upgrade` | | | **转到下一个发现结果** | Alt+F8 | | **转到上一个发现结果** | Shift+Alt+F8 | | **扫描工作区** — 打开每个候选文件，以便 LSP 对每个文件运行 `didOpen` | | | **更改分组** (发现结果视图) — 快速选择菜单：按严重程度 / 按文件 / 按规则 | | | **显示/隐藏严重程度** (发现结果视图) — 多选快速选择菜单，仅静音面板中的严重程度级别（编辑器界面不变） | | | **筛选发现结果** (发现结果视图) — 按规则 ID、消息或路径进行子字符串筛选 | | | **刷新** (发现结果视图) — 根据当前诊断流重新渲染 | | ## 工作区信任 Pipeline-Check 会生成配置的 Python 解释器来分析工作流文件。为了防止该子进程在首次打开新克隆的仓库时运行，扩展声明了 `capabilities.untrustedWorkspaces: "limited"` ——在获得工作区信任之前，它保持非活动状态。`serverCommand` / `serverArgs` 设置为 `machine-overridable`，因此即使获得信任后，恶意的 `.vscode/settings.json` 也无法静默交换解释器或注入任意参数。 ## 开发 ``` 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 ``` 在 VS Code 中打开此文件夹，然后按 F5 启动一个加载了扩展的扩展宿主实例。在 [.vscode/launch.json](.vscode/launch.json) 中提供了两个调试配置： - **运行扩展**：打开一个没有工作区的新窗口。在针对您自己代码的检出版本迭代客户端连接时使用此配置。 - **运行扩展 (示例工作流)**：将 `test-fixtures/sample-workflow/` 作为工作区打开。该测试固件是一个故意存在漏洞的 GitHub Actions 工作流，打开文件时应立即产生四个诊断（GHA-001, GHA-004, GHA-015, GHA-016）。这是确认客户端到服务器往返工作正常的最快方法。 ## 打包 ``` npm run package # delegates to `vsce package`, produces pipeline-check-.vsix ``` ## 发布 发布完全由 [.github/workflows/publish.yml](.github/workflows/publish.yml) 自动完成。将提交打上与 `package.json#version` 匹配的 `vX.Y.Z` 标签，推送标签，工作流将打包 `.vsix`，发布到 VS Code Marketplace 和 Open VSX，并将构件附加到 GitHub Release，同时使用匹配的 `CHANGELOG.md` 部分作为发布说明。 ``` git tag v0.1.2 git push origin v0.1.2 ``` **标签命名规范：** - `vX.Y.Z` → 稳定市场频道。 - `vX.Y.Z-rc.N`（或 semver 核心后带 `-` 的任何版本）→ 预发布频道；GitHub release 也会标记为 `prerelease`。 发布作业受两个仓库密钥控制，它们都作为 **环境密钥** 存储在 `production` GitHub 环境中（发布步骤运行前需要指定的审批人批准）： | 密钥 | 来源 | |---|---| | `VSCE_PAT` | Azure DevOps PAT，权限范围为 *Marketplace → Manage*，绑定到 `greylag-ci` 发布者。 | | `OVSX_PAT` | Open VSX 访问令牌，来自用户设置页面，绑定到 `greylag-ci` 命名空间。 | 每个 PR 和推送到 `main` 的提交都受到 [.github/workflows/ci.yml](.github/workflows/ci.yml) 的检查，在 `[ubuntu-latest, windows-latest, macos-latest]` 上运行：检查、类型检查、单元测试 (vitest)、打包冒烟测试（加载 `dist/extension.js` 以验证包可加载，`npm audit --omit=dev --audit-level=high`、`vsce package`，在 Linux 上运行 `@vscode/test-electron` 集成测试套件。发布日的意外情况因此得以减少。

架构

``` ┌──────────────────────┐ stdio JSON-RPC ┌──────────────────────────┐ │ VS Code extension │ ◀─────────────────────▶ │ pipeline_check.lsp │ │ (TypeScript, this │ │ (Python, pygls; lives in │ │ repo) │ │ dmartinochoa/pipeline- │ │ │ │ check) │ └──────────────────────┘ └──────────────────────────┘ ``` 扩展生成 `python -m pipeline_check.lsp` 作为子进程，并通过 stdin / stdout 交换 Language Server Protocol 消息。服务器读取与 CLI 相同的规则注册表，因此编辑器中的发现结果与 `pipeline_check --output json` 的输出逐字节匹配（位置转换除外）。

## 安全 通过 GitHub 的[私人漏洞报告](https://github.com/greylag-ci/pipeline-check-vscode/security/advisories/new)私下报告漏洞 —— 响应 SLA 和威胁模型请参阅 [SECURITY.md](SECURITY.md)。 ## 许可证 [MIT](LICENSE)。

标签：CI/CD 安全, DevSecOps, GNU通用公共许可证, Node.js, SOC Prime, Subfinder, TLS抓取, TypeScript, VS Code 扩展, 上游代理, 严重性分析, 云安全监控, 代码安全, 内联提示, 合规框架, 安全态势, 安全扫描, 安全插件, 开发工具, 开源框架, 持续交付, 持续集成, 推荐操作, 数据投毒防御, 时序注入, 漏洞枚举, 管道检查, 自动化攻击, 软件安全, 逆向工具, 静态分析, 风险扫描