Update Workflows to Version 0.18.5

[epiverse-trace-bot]

🤖 This is an automated build

Update Workflows from sandpaper version 0.16.12 -> 0.18.5

• Auto-generated by create-pull-request on 2026-02-03T02:02+00:00

[github-actions]

ℹ️ Modified Workflows

This pull request contains modified workflow files and no preview will be created.

Workflow files modified:

• .github/workflows/README.md
• .github/workflows/docker_apply_cache.yaml
• .github/workflows/docker_build_deploy.yaml
• .github/workflows/docker_pr_receive.yaml
• .github/workflows/pr-comment.yaml
• .github/workflows/pr-preflight.yaml
• .github/workflows/sandpaper-version.txt
• .github/workflows/update-cache.yaml
• .github/workflows/update-workflows.yaml

If this is not from a trusted source, please inspect the changes for any malicious content.

To fix the issue, add an explicit permissions block to the preflight job that disables the default GITHUB_TOKEN permissions. Since preflight only evaluates conditions and writes to $GITHUB_OUTPUT, it does not need to call any GitHub APIs, so the most restrictive and accurate setting is permissions: {} for that job. This prevents the token from having any scopes in this job even if the repo/org default is broader.

Concretely, in .github/workflows/docker_apply_cache.yaml, within the jobs.preflight section (around line 23), insert a permissions: {} line beneath runs-on: ubuntu-latest. No additional imports or methods are needed, and this does not change functionality because the job is not using the token.

In general, the workflow should define an explicit permissions block that restricts the default GITHUB_TOKEN permissions to the minimal scope needed, either at the workflow root (applying to all jobs that don’t override it) or per job. Jobs that only run shell commands or print messages should typically have permissions: {} (no token) or at most read‑only permissions like contents: read. Jobs that call actions needing specific scopes can override or extend this.

For this workflow, the simplest, non‑invasive fix is:

• Add a top‑level permissions block right after the on: section, setting contents: read. This documents that the default token is read‑only for this workflow and will be stable even if repo/org defaults change.
• Keep the existing permissions override on check-renv (id-token: write) as‑is so that job continues to function.
• The flagged job no-renv-cache-used (and other jobs without their own permissions) will then automatically inherit the safe read‑only token, which is more than sufficient for echoing a message and other simple steps.

All required changes are within .github/workflows/docker_apply_cache.yaml; no extra imports or methods are needed.

In general, the fix is to add an explicit permissions: block that constrains the GITHUB_TOKEN to the minimal scopes required. The recommended pattern is to set restrictive permissions at the workflow root, and then override with more permissive job-level permissions: only where strictly necessary.

For this specific workflow, we can safely set permissions: read-all at the workflow level because:

• The shown jobs primarily run checks, echo messages, and upload artifacts.
• actions/upload-artifact works with GITHUB_TOKEN at read-level (it writes to the workflow run’s artifacts, not the repo itself).
• The external action carpentries/actions/renv-checks@main already receives an explicit token: ${{ secrets.GITHUB_TOKEN }}, and typical operations (checking repo contents, labels, etc.) only need read access.

To implement this without changing behavior, we will:

• Add a single workflow-level permissions: block directly under the on: section (after line 15, before concurrency:).
• Use permissions: read-all, which is the concise equivalent of granting read-only for all scopes, matching the recommendation for least privilege and ensuring all jobs—including renv-cache-available on line 71—have constrained permissions unless individually overridden.
• Leave existing job structure and steps unchanged.

No additional imports or methods are required since this is only a YAML configuration change within .github/workflows/docker_apply_cache.yaml.

In general, the fix is to explicitly declare GitHub token permissions for workflows/jobs instead of relying on repository defaults. For a “preflight” job that only needs to read repository contents and metadata, contents: read is usually sufficient; you can extend this if the called actions require more, but start from a minimal set.

The best targeted fix here is to add a permissions block to the preflight job, mirroring CodeQL’s suggested minimal starting point. Since the snippet doesn’t show any write operations (no pushes, PR updates, etc.), we can safely restrict it to contents: read. This keeps functionality unchanged for typical read-only operations (checking refs, reading files), while ensuring the GITHUB_TOKEN can’t perform unnecessary writes. Concretely, in .github/workflows/docker_build_deploy.yaml, within the preflight job definition (lines 43–56), insert a permissions: section under runs-on: ubuntu-latest (and before outputs:) with contents: read. No imports or external dependencies are needed, as this is pure workflow configuration.

In general, the problem is fixed by explicitly defining a permissions block that restricts the GITHUB_TOKEN to the minimal required scopes. This can be set at the workflow root (applies to all jobs unless overridden) and optionally overridden per job for jobs that need additional permissions.

For this workflow, the best minimal change is:

• Add a root-level permissions block near the top (after on: or before env:) that sets contents: read. This documents and enforces least privilege for jobs like preflight and check-renv, which do not require write access.
• Keep the existing permissions block on the update_cache job, as it appears to legitimately need write access to contents, pull requests, actions, issues, and id-token to perform updates and create a pull request.
• No other behavior of the workflow changes; only the token permissions for jobs without explicit permissions are restricted.

Concretely, edit .github/workflows/update-cache.yaml to insert:

permissions:
  contents: read

after the on: block and before the existing env: block (around current line 28). No additional imports or methods are needed since this is YAML configuration only.

In general, this should be fixed by adding an explicit permissions: block with least privilege, either at the top level of the workflow (to apply to all jobs) or specifically for the record-cache-result job. Since other jobs in this workflow interact with AWS and caches but not with repository contents, a minimal, safe default is to set contents: read at the workflow level, which is equivalent to the recommended read‑only default. If any job needed write permissions to issues, PRs, or contents, that job could then override permissions locally.

The single best fix without changing functionality is: add a top‑level permissions: section after the on: block, setting contents: read. This constrains the GITHUB_TOKEN globally, including for record-cache-result, and documents the intended scope. No existing steps rely on higher privileges, so behavior remains unchanged in practice. No new imports or external dependencies are required; this is purely a YAML configuration change within .github/workflows/docker_apply_cache.yaml.

Concretely:

• In .github/workflows/docker_apply_cache.yaml, after the on: section (lines 3–14) and before concurrency:, insert:

  permissions:
    contents: read

• Leave the rest of the workflow as is, including the env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} line; the token will now be constrained to read‑only repository contents (which is sufficient, and in fact unused by current steps).