Bitwarden Workflow Linter Rules

Mechanical Rules — apply automatically

`name_capitalized`

• Trigger: A workflow-level or job-level name: value does not start with a capital letter.
• Fix: Capitalize the first character of the name value. Do not change anything else.

`permissions_exist`

• Trigger: A workflow or job is missing an explicit permissions: key.
• Fix: Add permissions: {} at the workflow level if all jobs are missing it, or at the individual job level if only some jobs are missing it. Prefer job-level permissions.

`pinned_job_runner`

• Trigger: A job's runs-on: uses an unpinned label.
• Fix: Replace with the current pinned equivalent:
• ubuntu-latest → ubuntu-24.04
• windows-latest → windows-2022
• macos-latest → macos-14

`step_pinned`

Bitwarden enforces two distinct pinning requirements depending on who owns the action. Steps with no uses: field and local actions (starting with ./) are skipped entirely.

• Trigger (internal actions): A uses: reference starting with bitwarden/ is not pinned to @main. Exception: references of the form bitwarden/sm-action[/path]@<any-ref> are compliant at any ref and never trigger this rule.
• Trigger (external actions): A uses: reference not starting with bitwarden/ is not pinned to a full 40-character commit SHA, or is missing an inline version comment.

• Fix (internal actions):
• Change the ref to @main (e.g., bitwarden/gh-actions/azure-login@v1 → bitwarden/gh-actions/azure-login@main)
• Do not resolve a SHA — @main is the required and compliant state.

• Fix (external actions):

1. Resolve the correct commit SHA via the GitHub API: gh api repos/{owner}/{repo}/commits/{ref} --jq '.sha' 2. Show the SHA and a verification link (https://github.com/{owner}/{repo}/commit/{sha}) to the user before applying. 3. Wait for the user to confirm the SHA. If they provide a different SHA, use that instead. 4. Replace the uses: value with {action}@{sha} and add a comment with the original tag: # {original-ref}

• Example: uses: actions/checkout@v4 → uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4

`underscore_outputs`

• Trigger: A multi-word output name in a $GITHUB_OUTPUT write or outputs: block uses hyphens or camelCase instead of underscores.
• Fix: Rename the output key to use underscores. Update all references to that output within the same file.

`job_environment_prefix`

• Trigger: An environment variable name at the job level does not follow SCREAMING_SNAKE_CASE.
• Fix: Rename to SCREAMING_SNAKE_CASE and update all usages within the job.

`check_pr_target`

• Trigger: A workflow using pull_request_target has jobs not restricted to the default branch.
• Fix: Add a condition to the affected jobs: if: github.ref == 'refs/heads/<default-branch>'. Determine the repo's default branch rather than assuming main. If the job already has an if: condition, combine with && (e.g., if: <existing-condition> && github.ref == 'refs/heads/<default-branch>').

Judgment Rules — pause and ask the user

`name_exists`

• Trigger: A workflow or job is missing a name: key entirely.
• Fix: Ask the user what name to use, then add a name: key at the correct level with a capitalized value.

`step_approved`

• Trigger: A step's uses: references an action not on the Bitwarden approved actions list.
• Options to present to the user:

1. Add to approved list — if the action is legitimate and has been reviewed and approved, add it to bitwarden/workflow-linter's approved actions config. 2. Replace — swap with an approved alternative that provides the same functionality. 3. Remove — delete the step if it is not essential.

• Do not make this change automatically. Show the unapproved action name, ask which option the user wants, then act.

`run_actionlint` (complex findings)

• Trigger: actionlint reports an error that is not a simple formatting issue (e.g., type mismatches in expressions, invalid context references, shell script errors).
• Action: Show the finding verbatim, suggest a fix based on actionlint's message, and ask the user to confirm before applying.
• Simple actionlint findings (e.g., shellcheck style warnings with a clear single-line fix) may be applied automatically.