Update Workflows to Version 0.18.4

[epiverse-trace-bot]

🤖 This is an automated build

Update Workflows from sandpaper version 0.16.12 -> 0.18.4

• Auto-generated by create-pull-request on 2026-01-27T01:20+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 explicitly declare limited permissions for the workflow or for individual jobs, instead of relying on repository defaults. For this workflow, the simplest and least intrusive fix is to add a top-level permissions block so that all jobs have minimal read-only permissions by default, and then keep any job-specific overrides (like id-token: write in check-renv) as they are.

Concretely, in .github/workflows/docker_apply_cache.yaml, add a workflow-level permissions section near the top (after description and before on:) that restricts the GITHUB_TOKEN to read-only repository contents. This will apply to preflight and all other jobs that do not define their own permissions. The existing permissions: id-token: write block on the check-renv job should remain unchanged, as it is already explicit and narrow. No imports or external definitions are needed, just this YAML addition.

In general, the problem is fixed by explicitly declaring a permissions block either at the workflow root (applies to all jobs without their own permissions) or per job, and setting the minimum required scopes. For jobs that do not interact with the repository or GitHub APIs, permissions: { contents: read } (or even permissions: {} in newer runners) is appropriate; for jobs that assume roles via OIDC, id-token: write may be needed; for jobs that trigger workflows via the GitHub API or gh CLI, actions: write and possibly contents: read or contents: write might be needed.

The single best way here, without changing existing functionality and with minimal intrusion, is to add a conservative permissions block at the workflow root that matches the most common needs, and then keep or refine job-specific overrides where already present. However, the instructions limit edits to the shown snippets and the CodeQL warning is tied specifically to the no-renv-cache-used job, so we will add a permissions block to that job alone. Since this job only prints a message, it does not need any token permissions; the safest configuration is to set contents: read as a minimal baseline (GitHub does not yet support an entirely empty permissions mapping in all contexts, and contents: read is the commonly recommended minimal setting).

Concretely, in .github/workflows/docker_apply_cache.yaml, within the no-renv-cache-used job definition (around lines 61–68), we will insert:

    permissions:
      contents: read

between runs-on: ubuntu-latest and needs: check-renv. No imports or additional definitions are required.

To fix the problem, explicitly define minimal permissions for jobs that currently inherit repository defaults. Since several jobs (no-renv-cache-used, renv-cache-available) only echo messages and do not need GitHub API access, they can safely set permissions: { contents: read } (or even permissions: {} in newer runtimes). For consistency and least privilege, it is often best to set a restrictive default at the workflow level and then override it only for jobs that need more (e.g., check-renv already needs id-token: write).

In this workflow, the cleanest minimal change—without altering existing behavior—is to add explicit read-only token permissions at the workflow root so all jobs have constrained permissions by default, and then keep the existing job-level permissions in check-renv (which will override the root). This addresses CodeQL’s complaint about renv-cache-available and any other jobs lacking a permissions block, without changing logic or steps. Concretely, in .github/workflows/docker_apply_cache.yaml, add a permissions: section near the top (after on: or after concurrency:) such as:

permissions:
  contents: read

No additional imports or dependencies are needed.

In general, the problem is fixed by adding an explicit permissions: block either at the top level of the workflow (to apply to all jobs without their own block) or per job, granting only the minimal permissions required. This overrides repository/organization defaults and enforces least-privilege access for the GITHUB_TOKEN.

For this workflow, the most precise and least intrusive fix is to add a permissions: block at the workflow root that is appropriately restrictive, and, if necessary, override it for individual jobs that require more. Based on the shown snippet, the jobs mostly perform checks, configure AWS credentials via OIDC, and upload to S3 with temporary AWS credentials; those do not require GitHub write permissions. The trigger-build-deploy job uses gh workflow run docker_build_deploy.yaml --ref main, which triggers another workflow in the same repository. That operation typically requires the actions: write (or workflow: write) permission, but it does not need write access to repository contents. A reasonable least-privilege configuration is: at the workflow level, set permissions: contents: read (the minimal recommendation from CodeQL), and for the trigger-build-deploy job add a more specific permissions: block that also grants actions: write (to allow triggering the other workflow) but still avoids contents: write.

Concretely:

• In .github/workflows/docker_apply_cache.yaml, just below the description: (line 2) and before the on: block, add a root-level permissions: section with contents: read.
• Within the trigger-build-deploy job (line 211 onwards), add a permissions: block under runs-on: that narrows or extends permissions as needed. To preserve functionality of gh workflow run while still being restrictive, give that job contents: read plus actions: write. No new imports or external dependencies are needed, since this is pure workflow YAML configuration.

In general, the problem is fixed by explicitly defining a permissions block either at the workflow root (to cover all jobs) or directly on the affected job. The block should grant only the minimal permissions needed. Since the full-build and update-container-version jobs already have their own explicit permissions, adding a restrictive permissions block to the preflight job avoids changing behavior of those other jobs while satisfying least-privilege for preflight.

The single best fix here is to add a permissions block to the preflight job that grants only read access to repository contents, which is sufficient for actions like actions/checkout and typical preflight logic. Concretely, in .github/workflows/docker_build_deploy.yaml, under jobs: preflight: and alongside keys like name, runs-on, outputs, and env, add:

permissions:
  contents: read

No additional imports or dependencies are needed; this is purely a configuration change in the workflow YAML. Existing functionality of other jobs is left untouched because they already override permissions locally.

In general, to fix this problem you should explicitly declare a permissions block at the workflow or job level, granting only the minimal scopes required. For jobs that do not use GITHUB_TOKEN (like a pure shell preflight), you can safely set permissions: { contents: read } at the workflow level, or even permissions: {} if no token is needed at all. Jobs that need broader access (like update_cache, which creates pull requests and writes contents) can keep or define their own more permissive permissions blocks that override the workflow default.

For this specific workflow, the best fix without changing functionality is to add a top‑level permissions block that limits the default GITHUB_TOKEN permissions for all jobs to read‑only repository contents. The existing permissions in the update_cache job should remain as‑is, since it clearly needs write access to contents, pull-requests, actions, issues, and id-token. The preflight and check-renv jobs will then inherit the read‑only default, which is sufficient because they only check conditions and run an action; they do not push commits or open PRs in the snippet shown.

Concretely:

• Edit .github/workflows/update-cache.yaml.
• Insert a workflow‑level permissions: block right after the on: block (after line 26, before the env: block) setting contents: read.
• Leave the existing permissions block in the update_cache job unchanged.

No additional imports, methods, or YAML keys are required beyond the new permissions block.