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-27T00:58+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 define minimal permissions for the workflow or for individual jobs that currently rely on implicit repository defaults. For jobs that do not interact with the GitHub API or modify repository state, you can safely set permissions: {} (no token permissions), or permissions: contents: read if a read-only token is needed. For jobs that need specific write scopes, you grant them narrowly (e.g., pull-requests: write).

For this workflow, the simplest and safest change that does not alter existing behavior is:

• Add an explicit, least-privilege permissions block at the top (workflow) level, right after the on: block. This will apply to all jobs that do not define their own permissions.
• The preflight job does not appear to use the GitHub API, so it can inherit a very restrictive token. A good baseline for most workflows is contents: read, which allows basic read operations but prevents writes.
• The check-renv job already has explicit permissions: id-token: write, and GitHub will merge this with workflow-level permissions, so we should not remove or change that; instead, we add the workflow-level permissions so that all other jobs are at least constrained to read-only contents.
• Other jobs shown (no-renv-cache-used, renv-cache-available, update-renv-cache, trigger-build-deploy) do not have explicit permissions; by setting the workflow-level permissions, we reduce their token privileges without changing their logic.

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 (line 17). No additional imports or definitions are needed.

---

In general, the fix is to define explicit permissions for the workflow so that the default GITHUB_TOKEN privileges are minimized, and then override them in individual jobs only where broader permissions are required. For jobs that do not need the token at all (like those just running echo or purely local commands), you can disable the token with permissions: {} or permissions: none. For jobs that need specific permissions, set only those scopes instead of broad write access.

The best way to fix this workflow without changing existing functionality is:

• Add a root-level permissions block (near the top of the file, alongside name, description, and on) that sets a safe default, e.g. contents: read. This will apply to all jobs that do not override permissions.
• The check-renv job already has permissions: id-token: write to support OIDC with AWS, so we leave it as-is.
• For jobs that clearly do not need GITHUB_TOKEN at all—no-renv-cache-used, renv-cache-available, and likely update-renv-cache and trigger-build-deploy—we should disable the token explicitly. However, we must not break existing functionality: the trigger-build-deploy job uses the gh CLI with GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}, which is not the implicit GITHUB_TOKEN but a secret; therefore, we can safely set permissions: {} or permissions: none there without affecting access to secrets.GITHUB_TOKEN. To directly address the CodeQL warning on the no-renv-cache-used job, we will add permissions: {} to that job; additionally, we should still add a root default to ensure the whole workflow is hardened.

Concretely:

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

  permissions:
    contents: read

  to define minimal default permissions for all jobs.
• In the no-renv-cache-used job (around line 61–69), add:

      permissions: {}

  so that this job gets no GITHUB_TOKEN at all, matching its actual needs and resolving the specific CodeQL complaint.

No new imports or external libraries are needed; these are pure YAML configuration changes.

In general, this issue is fixed by explicitly specifying a permissions block in the workflow so that GITHUB_TOKEN has only the minimal scopes required. This can be done at the workflow root (applies to all jobs that don’t override it) or at individual jobs. Since none of the shown jobs perform repository write operations and only read repository contents and metadata (plus assume AWS roles via OIDC and call gh workflow run), contents: read is an appropriate minimal starting point.

The best way to fix this without changing functionality is to add a workflow-level permissions block near the top of .github/workflows/docker_apply_cache.yaml, just after the on: block (or after concurrency:), setting contents: read. This will apply to all jobs (preflight, check-renv, no-renv-cache-used, renv-cache-available, update-renv-cache, trigger-build-deploy, etc.) that do not have their own permissions block and will satisfy CodeQL’s requirement to restrict GITHUB_TOKEN. No additional imports or external dependencies are required; this is a pure YAML configuration change.

Concretely:

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

permissions:
  contents: read

after the on: section (lines 3–14) or after the concurrency block (lines 16–19). Both are valid, but placing it immediately after on: is conventional and unambiguous. No other parts of the workflow need to be changed.

In general, the fix is to add an explicit permissions block to the preflight job (or at the workflow root) that grants only the minimal required scopes, instead of relying on inherited defaults. Since preflight is an analysis/orchestration job and does not appear to push commits, open PRs, or publish artifacts, it most likely only needs read access to the repository contents.

The safest change without altering functionality is to add permissions: contents: read directly under the preflight job definition. This limits the GITHUB_TOKEN for that job to read-only repository contents, while keeping the more permissive, already-declared permissions for the other jobs (full-build and update-container-version) unchanged. No imports or additional methods are required; this is a pure YAML configuration change in .github/workflows/docker_build_deploy.yaml.

Concretely, in .github/workflows/docker_build_deploy.yaml, modify the preflight job definition (around lines 39–52) to insert:

    permissions:
      contents: read

between runs-on: ubuntu-latest and outputs:. This applies least-privilege to the GITHUB_TOKEN used in that job.

In general, the problem is fixed by explicitly specifying a minimal permissions block for the GITHUB_TOKEN either at the workflow root (applies to all jobs that do not override it) or on each job. We should grant only the permissions needed: update_cache already has its job-level block; preflight and check-renv appear to require at most read access to repository contents for actions like actions/checkout. They do not create PRs, write issues, or modify repository state.

The best minimal fix without changing existing functionality is:

• Add a workflow-level permissions block after the on: section that sets contents: read. This becomes the default for preflight and check-renv.
• Leave the existing job-level permissions for update_cache unchanged so that job continues to have the broader rights it needs.

Concretely:

• Edit .github/workflows/update-cache.yaml.
• After line 26 (end of workflow_dispatch.inputs), insert:

permissions:
  contents: read

This ensures that:

• preflight and check-renv run with contents: read only.
• update_cache retains its existing explicit permissions block and overrides the default where necessary.

No additional imports, methods, or other definitions are needed.