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:40+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, to fix this class of issue you explicitly declare permissions either at the top level of the workflow or per job, limiting GITHUB_TOKEN to the minimum required scopes. Jobs that don’t need to touch the GitHub API at all can safely use permissions: {} (no permissions) or a read-only contents: read if they need to read repo data via the API.

For this specific workflow, the preflight job just evaluates the event context and sets an output. It does not use secrets.GITHUB_TOKEN, call the GitHub API, or perform any GitHub-side write actions. The safest and least-privilege configuration is therefore to give it no token permissions. Concretely, in .github/workflows/docker_apply_cache.yaml, under jobs: preflight:, add a permissions: {} block alongside runs-on and outputs. This change does not modify any existing behavior, because the job never used the token’s capabilities; it only tightens what the token would be allowed to do if the script were ever changed in the future.

In general, fix this by explicitly configuring GitHub Actions permissions so that jobs get only the minimal GITHUB_TOKEN capabilities they need. Jobs that do not need the token can set permissions: {} (no permissions), while jobs that need limited access can request only specific scopes (e.g., contents: read).

For this workflow, the simplest, least-disruptive fix centered on the flagged job is to add an explicit permissions: {} block to the no-renv-cache-used job. That job only prints a message and does not require any GitHub API operations or token use, so it can safely run with no token permissions at all. We do not need to change its steps or add any imports. Concretely, in .github/workflows/docker_apply_cache.yaml, under jobs: no-renv-cache-used:, insert a permissions: {} line between runs-on: ubuntu-latest and needs: check-renv. No other parts of the file need to be modified for this specific CodeQL report.

In general, the fix is to explicitly define a minimal permissions block at the workflow level so all jobs get least-privilege defaults, and then override permissions per job only where broader access is strictly required. This prevents jobs from inheriting potentially broad repository defaults.

The best targeted fix here is:

• Add a permissions block near the top of .github/workflows/docker_apply_cache.yaml (at the workflow root) to set contents: read and id-token: write (the latter is already required by check-renv). This will apply to all jobs that don’t define their own permissions.
• Remove the now-redundant permissions block from the check-renv job so it inherits the root-level settings.
• Leave other jobs as-is; they will automatically inherit the safe defaults, and trigger-build-deploy will still be able to use GITHUB_TOKEN with read-only repo contents, which is sufficient to invoke another workflow via gh workflow run (no package or admin writes are needed here based on the snippet).

Concretely:

• In .github/workflows/docker_apply_cache.yaml, after the on: block (after line 15), insert:

permissions:
  contents: read
  id-token: write

• In the check-renv job block, delete the permissions: stanza currently at lines 45–47.

No additional imports or methods are needed; this is purely YAML configuration.

In general, the problem is fixed by adding an explicit permissions block either at the top level of the workflow (applies to all jobs that don’t override it) or specifically to the jobs that need restricted permissions. This narrows the GITHUB_TOKEN scopes to the minimum necessary, rather than inheriting potentially broad repository defaults.

The best minimal fix here, without changing existing functionality, is to add a top-level permissions block with contents: read. All shown jobs only need to read repository metadata or contents (e.g., actions/checkout, conditional logic, and using gh workflow run which works with a read-contents token to inspect workflows and trigger runs). No code in the shown snippet writes to the repository (no pushes, no PR modifications, no release creation), so contents: read is sufficient and aligns with CodeQL’s suggested starting point. Adding this block near the top of .github/workflows/docker_apply_cache.yaml, aligned with name, description, and on, ensures the whole workflow token is restricted. No other imports or definitions are required.

Concretely:

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

permissions:
  contents: read

after the description line (line 2) and before the on: line (line 3), maintaining YAML indentation (no leading spaces since it’s top-level). No other lines need to change.

Generally, to fix this problem, you add a permissions block either at the workflow root (to affect all jobs) or on the specific job(s) that use GITHUB_TOKEN, granting only the minimal scopes needed (e.g., contents: read). This prevents the workflow from inheriting broader default repository permissions.

For this workflow, other jobs (full-build and update-container-version) already have explicit permissions tailored to their needs. The missing piece is the preflight job. To avoid changing existing behavior while following least-privilege, we should add a permissions block to preflight that grants read-only access to repository contents, which is sufficient for typical preflight checks and for actions that only need to read repository data. Specifically, in .github/workflows/docker_build_deploy.yaml, under the preflight job definition (around line 39–52), insert:

    permissions:
      contents: read

This ensures preflight no longer relies on default permissions and documents its intended minimal access. No additional methods, imports, or external definitions are required; this is purely a workflow configuration change.

In general, the fix is to explicitly define a permissions block either at the workflow root (applying to all jobs without their own block) or for each job, and restrict the GITHUB_TOKEN as much as possible, typically to contents: read for jobs that only need to read the repository. For jobs that truly do not need the token at all, permissions: {} or permissions: none can be used.

For this workflow, the most conservative change that does not alter existing behavior is:

• Add a root-level permissions block after the on: section, setting contents: read. This safely covers preflight and check-renv, which only read repo content (checkout) or do not use the token explicitly.
• Keep the existing explicit permissions block on the update_cache job, which already grants the necessary write scopes; per GitHub semantics, job-level permissions override the workflow default, so there is no behavior change for that job.

The concrete change in .github/workflows/update-cache.yaml is to insert:

permissions:
  contents: read

after line 26 (the end of the on.workflow_dispatch.inputs section) and before the existing env: block. No additional imports or definitions are required.