Update Workflows to Version 0.18.3

[epiverse-trace-bot]

🤖 This is an automated build

Update Workflows from sandpaper version 0.16.12 -> 0.18.3

• Auto-generated by create-pull-request on 2026-01-20T02:03+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 problem is fixed by explicitly defining GitHub Actions permissions, either at the workflow root (applies to all jobs that don't override it) or per job. For a job that does not need any token permissions, we should set permissions: {} to fully disable the GITHUB_TOKEN. For jobs that do need specific scopes, we grant only those scopes.

The minimal, least-privilege change here is:

• Add a workflow-level permissions: read-all (or equivalent) if we want a common default, and then override for individual jobs as needed; or
• More strictly, add a job-level permissions: {} to preflight, since it only runs a bash condition and does not need GITHUB_TOKEN at all.

Because we must avoid changing functionality and we only know the full needs of the shown jobs, the safest targeted change is:

• Add permissions: {} to the preflight job to explicitly disable GITHUB_TOKEN there.
• Keep the existing permissions block in check-renv unchanged.
• Leave other jobs untouched since they are not part of the finding and their permission needs are not fully visible.

Concretely, in .github/workflows/docker_apply_cache.yaml, under jobs.preflight, insert a permissions: {} entry between runs-on: ubuntu-latest (line 24) and outputs: (line 25). No imports or additional methods are needed; this is a pure YAML configuration change.

In general, the issue is fixed by explicitly specifying GitHub Actions permissions to follow least privilege, either at the workflow root (applies to all jobs without their own block) or per job. For a job that only runs a simple shell command and does not call the GitHub API, the correct least privilege is permissions: {} to disable the GITHUB_TOKEN entirely for that job.

The best minimal change that does not alter existing functionality is to add a permissions: {} block to the no-renv-cache-used job. That job currently only prints a message and does not use GITHUB_TOKEN, so removing token permissions will not affect behavior. We leave other jobs unchanged, including check-renv which already has an explicit permissions block.

Concretely, in .github/workflows/docker_apply_cache.yaml, under the no-renv-cache-used: job definition (around line 62), insert permissions: {} between runs-on: ubuntu-latest and needs: check-renv. No imports or additional methods are required because this is pure YAML configuration.

To fix the problem, the job that currently has no explicit permissions block (renv-cache-available) should be given explicit, least‑privilege GitHub token permissions. Since this job only prints a message and does not use the token at all, the safest option is to disable the token for this job by setting permissions: {}. This ensures that even if future steps are added inadvertently, they will not have implicit read‑write access without consciously adjusting permissions.

Concretely, in .github/workflows/docker_apply_cache.yaml, locate the renv-cache-available job starting at line 70 (name: "renv cache available"). Under runs-on: ubuntu-latest (line 72), add a permissions: {} block at the same indentation level as runs-on, needs, and if. No imports or additional definitions are needed; this is purely a YAML configuration change within the workflow.

In general, to fix this class of problem you explicitly declare a permissions: block in the workflow or specific jobs, limiting the default GITHUB_TOKEN scopes to only what is required (e.g., contents: read). This overrides potentially broader repo/org defaults and aligns with least privilege.

For this specific workflow, the best minimally invasive fix without changing behavior is to add a single top‑level permissions: block applying to all jobs. This will also address the CodeQL warning on the trigger-build-deploy job. Place the block after the on: section (a common, clear location) and set contents: read, which is sufficient for actions/checkout@v4 and for using the GitHub CLI with GITHUB_TOKEN to trigger another workflow. No other scopes (like issues or pull-requests) are clearly required from the provided snippet.

Concretely:

• Edit .github/workflows/docker_apply_cache.yaml.
• Insert:

permissions:
  contents: read

between the on: block (ending at line 14) and the concurrency: block (starting at line 17). No additional imports or dependencies are needed.

In general, the fix is to add an explicit permissions block to the preflight job so that the automatically provided GITHUB_TOKEN is restricted to the least privilege required. Since this job primarily runs preflight checks and determines whether to build, it likely only needs read access to repository contents (and possibly nothing more). This aligns it with the other jobs in the workflow that already declare scoped permissions.

Concretely, in .github/workflows/docker_build_deploy.yaml, under the preflight job definition (around lines 39–52), add a permissions section specifying contents: read. Place it at the same indentation level as runs-on, outputs, env, and steps. This will ensure that the implicit GITHUB_TOKEN used by this job is limited to read-only access to repository contents, while not changing any of the existing environment variables, steps, or behavior. No additional imports or external dependencies are required; this is purely a workflow configuration change.

In general, the problem is fixed by explicitly defining a restrictive permissions block at the root of the workflow, which applies to all jobs that do not have their own permissions block. Jobs that need broader permissions (like update_cache) can continue to override permissions at the job level.

For this workflow, the best minimal change that preserves functionality is:

• Add a workflow-level permissions block just after the on: section.
• Set contents: read as a sensible least-privilege default for preflight and check-renv, which only need to read repo contents and metadata.
• Leave the existing permissions block under the update_cache job unchanged so it preserves its required write permissions.

Concretely:

• Edit .github/workflows/update-cache.yaml.
• Insert:

permissions:
  contents: read

between the on: block (ending at line 26) and the env: block (starting at line 28). No imports or additional definitions are required, since this is a pure YAML configuration change within the workflow.