Update Workflows to Version 1.0.0

[epiverse-trace-bot]

🤖 This is an automated build

Update Workflows from sandpaper version 0.16.12 -> 1.0.0

• Auto-generated by create-pull-request on 2026-03-17T01:53+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
• .github/workflows/workflows-version.txt

If this is not from a trusted source, please inspect the changes for any malicious content.

In general, fix this by explicitly declaring a permissions block either at the workflow root or per job, granting only the minimal scopes needed. Jobs that do not need GITHUB_TOKEN at all can use permissions: {} (or permissions: { contents: read } if read access is required).

For this workflow, the preflight job does not interact with the repository, GitHub API, or any actions that require authentication; it simply inspects github context variables and sets an output. The safest, least-privilege fix is to add permissions: {} to that job so that GITHUB_TOKEN is not granted. Concretely, in .github/workflows/docker_apply_cache.yaml, under jobs: preflight:, insert a permissions: {} block aligned with other job keys (e.g., between runs-on: ubuntu-latest and outputs:). No imports or additional definitions are needed.

In general, to fix this kind of issue you either (a) add a top-level permissions block to the workflow to set minimal defaults for all jobs, or (b) add a per-job permissions block to each job, granting only what that job needs. Jobs that do not interact with the GitHub API or repository contents can set permissions: {} (or omit specific scopes) to effectively disable GITHUB_TOKEN.

For this specific workflow and the highlighted no-renv-cache-used job, the single best minimal change is to add a permissions: {} block to that job so it does not receive a token at all, without altering any behavior. This job only prints a message; it does not use GITHUB_TOKEN or perform any GitHub operations. Therefore, we can safely disable permissions entirely for this job.

Concretely:

• Edit .github/workflows/docker_apply_cache.yaml.
• In the no-renv-cache-used job definition (around lines 61–69), insert a permissions: {} block between runs-on: ubuntu-latest and needs: check-renv, respecting YAML indentation.
• No imports or other definitions are needed, because this is a YAML workflow configuration change only.

In general, the fix is to add an explicit permissions: block with the minimal scopes each job actually needs. For jobs that never call GitHub APIs or use actions that require the token, you can typically set permissions: { contents: read } or even permissions: {} (no permissions) if nothing requires the token. Jobs that need to push commits, create releases, or otherwise modify repository state should be given only the specific write scopes they need (e.g., contents: write, pull-requests: write, etc.).

For this specific workflow, the renv-cache-available job (lines 70–77) only runs a shell command that prints a message and does not use GITHUB_TOKEN or any GitHub API–using action. It therefore doesn’t need any permissions at all. The safest least‑privilege fix, without changing functionality, is to add permissions: {} to that job so that the GITHUB_TOKEN has no associated scopes there. This change should be placed under the job’s other top-level keys (e.g., after if: or needs:), following YAML structure. No imports or additional definitions are needed, as this is a YAML configuration change only.

To fix the problem, explicitly declare least‑privilege permissions for the preflight job so it no longer relies on repository/organization defaults. This documents what the job needs and prevents accidental elevation if defaults change or the workflow is copied elsewhere.

The single best fix with minimal functional change is:

• Add a permissions block under jobs.preflight that grants only read access to repository contents, which is sufficient for typical preflight/check/checkout operations:
  • contents: read
• Do not alter the existing permissions of other jobs (full-build, update-container-version), as those are already explicitly defined and may require writes.

Concretely:

• In .github/workflows/docker_build_deploy.yaml, under the preflight job (lines 44–57 region), insert:

    permissions:
      contents: read

between runs-on: ubuntu-latest and outputs:. No new imports or external dependencies are needed; this is pure workflow configuration.

In general, the fix is to explicitly declare a permissions block for jobs that currently rely on default GITHUB_TOKEN permissions, restricting them to the minimum needed (or to none if the job does not require the token). This documents the intent and prevents the job from accidentally gaining broader privileges if repo defaults change.

For this workflow, the preflight job only runs a bash script and does not need to access repository contents or any GitHub APIs. The safest, least-privilege option is to add permissions: {} to that job, which disables the GITHUB_TOKEN for it. This leaves the existing update_cache job’s explicit permissions unchanged. Concretely, in .github/workflows/update-cache.yaml, under jobs: preflight:, insert a permissions: {} line just after runs-on: ubuntu-latest (around line 36). No other imports or definitions are needed.

In general, the fix is to add an explicit permissions block that restricts the GITHUB_TOKEN to the least privileges required. This can be added at the root of the workflow (applying to all jobs that don’t override it) or per job. Since the CodeQL finding is on the record-cache-result job, and based on the visible behavior that job only uploads an artifact and does not require repository write access, the best fix is to add permissions: contents: read to that job (or an equivalent minimal set such as permissions: {} if absolutely nothing is required, though actions/upload-artifact typically assumes basic repo read context).

Concretely, in .github/workflows/docker_apply_cache.yaml, under jobs: record-cache-result:, add a permissions: block before runs-on:. This will ensure that for this job the GITHUB_TOKEN has only read access to repository contents, which is sufficient for common marketplace actions that only need to identify the repo and workflow run, and avoids unintended write capabilities. No additional imports or methods are needed; it is purely a YAML configuration change.