bitwarden-workflow-linter-rules

机械规则 — 自动应用

name_capitalized

• 触发条件： 工作流级或作业级的 name: 值不是以大写字母开头。
• 修复： 将名称值的首字符改为大写。不要更改其他内容。

permissions_exist

• 触发条件： 工作流或作业缺少显式的 permissions: 键。
• 修复： 如果所有作业都缺少该键，则在工作流级添加 permissions: {}；如果只有部分作业缺少，则在相应作业级添加。优先使用作业级权限。

pinned_job_runner

• 触发条件： 作业的 runs-on: 使用了未固定的标签。
• 修复： 替换为当前固定版本：
  • ubuntu-latest → ubuntu-24.04
  • windows-latest → windows-2022
  • macos-latest → macos-14

step_pinned

Bitwarden 会根据操作的所有者应用两种不同的固定要求。没有 uses: 字段的步骤和本地操作（以 ./ 开头）会被完全跳过。

• 触发条件（内部操作）： 以 bitwarden/ 开头的 uses: 引用未固定到 @main。例外：形如 bitwarden/sm-action[/path]@<any-ref> 的引用无论使用何种 ref 均符合要求，不会触发此规则。

• 触发条件（外部操作）： 不以 bitwarden/ 开头的 uses: 引用未固定到完整的 40 个字符提交 SHA，或缺少行内版本注释。

• 修复（内部操作）：

  • 将 ref 改为 @main（例如：bitwarden/gh-actions/azure-login@v1 → bitwarden/gh-actions/azure-login@main）
  • 不要解析 SHA — @main 是必需且合规的状态。

• 修复（外部操作）：

  1. 通过 GitHub API 解析正确的提交 SHA：gh api repos/{owner}/{repo}/commits/{ref} --jq '.sha'
  2. 在应用更改前，向用户显示 SHA 和验证链接（https://github.com/{owner}/{repo}/commit/{sha}）。
  3. 等待用户确认 SHA。如果用户提供了不同的 SHA，则使用该 SHA。
  4. 将 uses: 值替换为 {action}@{sha}，并添加包含原始标签的注释：# {original-ref}
  • 示例： uses: actions/checkout@v4 → uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4

underscore_outputs

• 触发条件： $GITHUB_OUTPUT 写入或 outputs: 块中的多词输出名称使用连字符或驼峰命名，而不是下划线。
• 修复： 将输出键名改为使用下划线。更新同一文件中对此输出的所有引用。

job_environment_prefix

• 触发条件： 作业级环境变量名称不符合 SCREAMING_SNAKE_CASE 格式。
• 修复： 重命名为 SCREAMING_SNAKE_CASE，并更新该作业中的所有用法。

check_pr_target

• 触发条件： 使用 pull_request_target 的工作流中，作业未限制在默认分支上运行。
• 修复： 为受影响的作业添加条件：if: github.ref == 'refs/heads/<default-branch>'。应确定仓库的默认分支，而不是假定为 main。如果作业已有 if: 条件，则使用 && 组合（例如：if: <existing-condition> && github.ref == 'refs/heads/<default-branch>'）。

判断规则 — 暂停并询问用户

name_exists

• 触发条件： 工作流或作业完全缺少 name: 键。
• 修复方法： 询问用户要使用什么名称，然后在正确的层级添加 name: 键，并设置一个首字母大写的值。

step_approved

• 触发条件： 某个步骤的 uses: 引用了不在 Bitwarden 已批准操作列表中的操作。
• 向用户提供以下选项：
  1. 添加到已批准列表 — 如果该操作合理且已审核并获批，则将其添加到 bitwarden/workflow-linter 的已批准操作配置中。
  2. 替换 — 替换为具有相同功能的已批准替代方案。
  3. 移除 — 如果该步骤并非必要，则将其删除。
• 不要自动进行此更改。显示未批准的操作名称，询问用户想选择哪个选项，然后再执行。

run_actionlint（复杂问题）

• 触发条件： actionlint 报告的错误并非简单的格式问题（例如，表达式中的类型不匹配、上下文引用无效、Shell 脚本错误）。
• 处理方式： 原样显示问题，根据 actionlint 的消息提出修复建议，并在应用前征求用户确认。
• 简单的 actionlint 问题（例如有明确单行修复方法的 shellcheck 风格警告）可以自动修复。