无需登录 数据私有 本地保存

CI/CD 流水线配置验证器 - 检查 GitHub Actions 语法

DevOps 开发工具 CI/CD 流水线 配置 验证
39
0
0
0

CI/CD 流水线验证器

GitHub Actions
待验证 0 行 · 0 jobs · 0 steps
1
等待验证...
粘贴或编辑 YAML 配置后点击验证
常见问题与知识点

一个有效的 GitHub Actions workflow 文件必须包含 on 和 jobs 两个顶级字段。on 定义触发事件（如 push、pull_request），jobs 定义要执行的任务集合。name 字段是可选的但强烈推荐，它让 workflow 在 GitHub UI 中更易于识别。此外，permissions 字段用于声明 GITHUB_TOKEN 的权限范围，是安全最佳实践。

是的，每个 job 必须包含 runs-on 和 steps。runs-on 指定运行器类型（如 ubuntu-latest、windows-latest），steps 是一个序列，每个步骤要么使用 uses 引用一个 action，要么使用 run 执行 shell 命令。缺少任一字段都会导致 workflow 解析失败。

最常见的缩进错误包括：混用空格和 Tab 键（YAML 不允许 Tab 缩进）、缩进层级不一致（应统一使用 2 个空格）、列表项的 - 缩进不正确（应与父级键对齐或缩进 2 格）。建议在编辑器中开启"显示空白字符"功能，并配置 Tab 键插入 2 个空格。使用本验证器可以快速检测这些缩进问题。

actions/checkout 是 GitHub 官方提供的最常用的 action，用于将仓库代码签出到运行器上。几乎所有 workflow 的第一步都应该是 uses: actions/checkout@v4（建议使用最新主版本 v4）。如果没有这一步，后续步骤将无法访问仓库中的源代码。常见错误是忘记包含此步骤或使用了过时的版本（如 v1、v2）。

permissions 字段用于控制 GITHUB_TOKEN 的访问权限，遵循最小权限原则。可以在 workflow 顶级或 job 级别设置。推荐显式声明所需权限，例如只读仓库内容：permissions: { contents: read }。如果不设置，默认拥有较多权限，可能带来安全风险。对于公开仓库的 fork PR，权限会自动受限。

调试 workflow 的常用方法包括：① 在 GitHub 仓库的 Actions 标签页查看详细日志；② 使用 act 工具在本地模拟运行（nektos/act）；③ 添加调试输出，如 echo "DEBUG: ${{ github.event }}"；④ 启用 step debug logging，在仓库设置中开启；⑤ 使用本验证器在提交前检查语法错误，避免因 YAML 格式问题导致的失败。

常用触发事件包括：push（代码推送）、pull_request（PR 活动）、schedule（定时触发，使用 cron 表达式）、workflow_dispatch（手动触发）、release（发布活动）、issues（议题活动）等。可以指定分支过滤：push: { branches: [main, develop] }，也可以使用路径过滤减少不必要的触发。

needs 字段用于定义 job 之间的依赖关系，确保某个 job 在指定的其他 job 成功完成后才运行。例如：deploy: { needs: [build, test], runs-on: ubuntu-latest, ... }。如果依赖的 job 失败或被跳过，当前 job 也会被跳过。这可以构建复杂的 CI/CD 流水线，如"构建 → 测试 → 部署"的顺序执行。
🔧 相关工具