Confirm statuses:write is the correct minimum permission for super-linter (not checks:write)

[Copilot]

The question was whether statuses: write could be replaced with checks: write as the minimum job permission for Super-Linter.

Inspecting the v8.6.0 source directly: lib/linter.sh constructs GITHUB_STATUS_URL as /repos/{owner}/{repo}/statuses/{sha} and lib/functions/output.sh posts to it via CreateGitHubCommitStatus. This is the Commit Statuses API — Super-Linter never touches the Checks API.

• statuses: write — required; keeps the existing permission unchanged
• checks: write — would be insufficient; Super-Linter doesn't use the Checks API

Updated the comment on statuses: write to document this so future readers don't repeat the investigation:

permissions:
  contents: read
  packages: read
  # Required: super-linter uses the GitHub Commit Statuses API
  # (/repos/{owner}/{repo}/statuses/{sha}), not the Checks API,
  # so statuses:write is the correct minimum permission (not checks:write)
  statuses: write

Original prompt

Update the workflow .github/workflows/super-linter.yml in repository nietras/Sep to use the minimum required GitHub Actions job permissions for Super-Linter. Investigate what permissions the currently pinned Super-Linter action version requires to report results. If checks: write is sufficient, replace statuses: write with checks: write. If both are required, keep the minimum correct set and explain why in the PR description. Preserve existing workflow structure and formatting as much as possible. Create a pull request with the change.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Suggest improvements to this code.

Assistant: This snippet is mostly good, but there is one likely permission smell:

Code smell / risk

• Possibly over-broad job permission: statuses: write is only needed if the action actually writes commit status checks through the Statuses API. Many modern GitHub Actions use the Checks API instead, which would require checks: write rather than statuses: write.
• In other words, this may be more privilege than necessary or even the wrong privilege, depending on how super-linter reports results.

Improvement options

Option 1: Keep only the minimum permission actually required

If super-linter truly needs commit status updates, keep it as-is, but consider documenting why at the permission itself:

permissions:
  contents: read
  packages: read
  # Required by super-linter to publish commit status results
  statuses: write

This is a small improvement, but it makes the security intent clearer.

Option 2: Prefer checks: write if the action uses check runs

If the linter publishes GitHub check runs rather than classic commit statuses, switch to:

permissions:
  contents: read
  packages: read
  checks: write

This is better aligned with current GitHub Actions patterns and least-privilege practice.

Option 3: Support both, then trim after verification

If you're unsure which API super-linter uses in this repo/version, temporarily allow both, verify behavior, then remove the unused one:

permissions:
  contents: read
  packages: read
  checks: write
  statuses: write

After confirming which permission is actually needed, remove the other one.

Recommended final version

If you want the safest improvement path without breaking reporting, I’d suggest verifying the action behavior and then using the narrowest correct permission. For example, if check runs are what’s needed:

jobs:
  build:
    name: super-linter
    runs-on: ubuntu-latest

    permissions:
      contents: read
      packages: read
      checks: write

    steps:
      - name: Harden Runner
        uses: step-security/harden-runner@a5ad31d6a139d249332a2605b85202e8c0b78450 # v2.19.1
        with:
          egress-policy: audit

      - name: Checkout code
        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
        with:
          fetch-depth: 0

      - name: Super-linter
        uses: super-linter/super-linter@9e863354e3ff62e0727d37183162c4a88873df41 # v8.6.0
        env:
          VALIDATE_GITHUB_ACTIONS: false
          VALIDATE_GITHUB_ACTIONS_ZIZMOR: false
          VALIDATE_BIOME_FORMAT: false
          VALIDATE_BIOME_LINT: false
          VALIDATE_EDITORCONFIG: false
          VALIDATE_CSHARP: false
          VALIDATE_DOTNET_SLN_FORMAT_ANALYZERS: false
          VALIDATE_DOTNET_SLN_FORMAT_STYLE: false
          VALIDATE_DOTNET_SLN_FORMAT_WHITESPACE: false
          VALIDATE_MARKDOWN_PRETTIER: false
          VALIDATE_GIT_COMMITLINT: false
          VALIDATE_JSCPD: false
          FILTER_REGEX_EXCLUDE: "./benchmarks/.*"
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

YAML / GitHub Actions best-practice note

For GitHub Actions workflows specifically, the main best practice here is least privilege. Since you already set permissions: read-all at the workflow level, overriding at the job level is good practice. The only thing to improve is making sure the write scope is exactly the one the action needs.

If you want, I can also suggest improvements for the rest of this workflow, not just the statuses: write line.

User: check what super linter needs and change to checks if that is enough in new pr

Assistant: I’ve started the PR creation flow and we’re currently waiting for your response to the confirmation dialog before I can continue.

This pull request was created from Copilot chat.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.64%. Comparing base (301dc9d) to head (6cfc72b).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #540      +/-   ##
==========================================
+ Coverage   99.58%   99.64%   +0.06%     
==========================================
  Files          57       57              
  Lines        4815     4815              
  Branches      540      540              
==========================================
+ Hits         4795     4798       +3     
  Misses         14       14              
+ Partials        6        3       -3     

Flag	Coverage Δ
Debug	99.37% <ø> (+0.10%)	⬆️
Release	99.61% <ø> (ø)
macos-latest	93.93% <ø> (ø)
ubuntu-24.04-arm	93.93% <ø> (ø)
ubuntu-latest	92.75% <ø> (+0.10%)	⬆️
windows-11-arm	93.93% <ø> (ø)
windows-latest	92.64% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.