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-24T02:33+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.

In general, the fix is to add an explicit permissions block to the workflow, at either the workflow root (to apply to all jobs) or to individual jobs, and set the minimum required permissions. For jobs that do not need GITHUB_TOKEN at all, permissions: {} or permissions: read-all or permissions: contents: read are typical; for jobs that need to assume AWS roles via OIDC, id-token: write must be granted.

The best fix here without changing functionality is:

• Add a root-level permissions block that restricts the default token permissions for all jobs to read-only repository contents:
  permissions: contents: read.
• Keep the existing, more specific permissions block on check-renv (id-token: write), which will override the root default for that job.
• The preflight, no-renv-cache-used, renv-cache-available, update-renv-cache, and record-cache-result jobs do not appear to need write permissions, so inheriting contents: read is safe and minimal.

Concretely, edit .github/workflows/docker_apply_cache.yaml:

• Insert a root-level permissions block after the on: section (after line 14–15, before concurrency:), with:

  permissions:
    contents: read

No new methods, imports, or other definitions are needed; this is pure workflow configuration.

In general, fix this by explicitly setting a restrictive permissions block at the workflow root (so it applies to all jobs by default) and then overriding it only in jobs that require broader or specialized permissions. For jobs that do not need to write to the repository or other resources via GITHUB_TOKEN, permissions: contents: read (or even permissions: {} if truly no token is needed) is sufficient.

For this file, the best minimal change without altering functionality is:

• Add a root-level permissions block after the on: section, setting contents: read. This will constrain the default GITHUB_TOKEN permissions for all jobs.
• Keep the existing permissions block in the check-renv job as-is; GitHub will merge/override appropriately, and id-token: write is still allowed alongside the root defaults.
• No changes are needed per-job (including no-renv-cache-used), since the root-level block is enough to satisfy the CodeQL warning and enforce least privilege.

Concretely, edit .github/workflows/docker_apply_cache.yaml to insert:

permissions:
  contents: read

between the on: block (ending at line 14) and the concurrency: block (starting at line 17). No imports or external libraries are involved.

In general, the fix is to explicitly add a permissions: block to the workflow or each job, setting the minimum required scopes (often contents: read, or even permissions: {} / permissions: read-all / permissions: write-all depending on needs). For jobs that do not require the GITHUB_TOKEN at all (no repository writes, no API calls, no actions that implicitly need it), we can set permissions: {} (or permissions: none on newer runners) at the job level to prevent the token from being granted.

In this specific workflow snippet, the renv-cache-available job only runs a single shell command that echoes a message and does not interact with the GitHub API, repository contents, or other securable resources. Therefore, the best minimal fix, without changing any behavior, is to add an explicit permissions: {} block to that job so that CodeQL recognizes that this job’s GITHUB_TOKEN is fully disabled. We will insert this directly under the job header (near the other job-level keys like runs-on and needs). Other jobs (e.g., update-renv-cache, record-cache-result) may legitimately require some permissions, but the error CodeQL highlighted is specifically for the renv-cache-available job; we will confine our change to that job only as per the instructions.

In general, the fix is to explicitly declare a permissions block to scope down the GITHUB_TOKEN privileges for the affected job (or at the workflow root). For the highlighted preflight job, we should add a job-level permissions section with the minimal permissions needed. Based on the snippet, preflight mainly performs checks, checks out the repository, and calls Carpentries actions likely needing to read repository contents and perhaps workflow metadata, but not to write code, issues, or PRs. A safe minimal starting point consistent with the CodeQL suggestion is contents: read. If additional scopes were needed later, they can be added explicitly.

Concretely, in .github/workflows/docker_build_deploy.yaml, inside the preflight job, add a permissions: mapping aligned with other job keys (e.g., same indentation as runs-on: and outputs:). Place it after runs-on: ubuntu-latest (or before outputs:) for clarity:

    permissions:
      contents: read

This does not change existing functionality except to limit what the default token can do to read-only on repository contents for this job, which is the intended least-privilege configuration. No new methods, imports, or external dependencies are required because this is a pure workflow-configuration change.

In general, the fix is to define an explicit permissions: block that grants only the minimal required scopes. You can do this either at the workflow root (applies to all jobs without their own permissions) or per job. Since update_cache already has its own explicit (and broader) permissions, the cleanest fix is to add a restrictive permissions: block at the workflow root that applies to preflight and check-renv, while leaving update_cache unchanged.

Concretely, in .github/workflows/update-cache.yaml, add a top-level permissions: section after the on: block and before env:. Set it to read-only repository access, which is the minimal safe default for most workflows that only need to read the code or metadata. A typical least-privilege baseline is:

permissions:
  contents: read

Both preflight and check-renv only read metadata and repository content (via actions/checkout and an external composite action), and do not require write access, so contents: read is sufficient. The update_cache job already has its own permissions: block including contents: write, pull-requests: write, etc., which will override the workflow default for that job, so we should not change that block.

No new imports or external libraries are needed; this is purely a YAML configuration change within the shown workflow file.

In general, the fix is to add an explicit permissions block that limits the GITHUB_TOKEN to the least privileges needed. Since the shown jobs only run shell commands, configure AWS credentials, upload to S3, and upload artifacts (all of which do not require repository write access), we can set contents: read at the workflow level, which is the minimal standard baseline and matches GitHub’s recommended starting point.

The single best fix, without changing existing functionality, is:

• Add a root-level permissions: block after the on: section, setting contents: read.
• This applies to all jobs (preflight, check-renv, no-renv-cache-used, renv-cache-available, update-renv-cache, and record-cache-result) unless they override it.
• No additional imports, methods, or YAML keys are necessary; this is a purely declarative change.

Concretely, in .github/workflows/docker_apply_cache.yaml, insert:

permissions:
  contents: read

between the existing on: block (line 3–14) and the concurrency: block (line 16–19). This keeps behavior identical while ensuring that GITHUB_TOKEN is restricted to read-only access to repository contents.