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-03T01:17+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.

To fix the issue, add an explicit permissions block to the preflight job (the one starting at line 22). Since this job only runs a shell script and does not interact with repository contents, PRs, or other resources via the GitHub API, it can safely be restricted to contents: read (or even contents: none; however, contents: read is a very common minimal default and matches the query’s recommended pattern). This explicitly documents and constrains the GITHUB_TOKEN permissions for that job while leaving the behavior of the workflow unchanged.

Concretely:

• In .github/workflows/docker_apply_cache.yaml, within the preflight job definition (lines 22–38), insert a permissions: section under runs-on: ubuntu-latest, setting contents: read.
• No additional imports, methods, or definitions are needed; this is a pure YAML configuration change.

In general, the fix is to explicitly set a permissions block to restrict GITHUB_TOKEN to the least privilege needed. This can be done either at the workflow root (applies to all jobs that don’t override it) or per job. Since one job (check-renv) already has its own permissions block, the cleanest approach is to set a minimal read-only default at the workflow level and leave check-renv’s specific id-token: write override as-is.

Concretely:

• Add a root-level permissions: block near the top of .github/workflows/docker_apply_cache.yaml (e.g., after the on: section and before concurrency:) that sets contents: read. This is a safe, minimal default that will apply to jobs such as preflight, no-renv-cache-used, renv-cache-available, update-renv-cache, and record-cache-result, none of which need write access to repository contents.
• Keep the existing permissions block for check-renv unchanged so it can still obtain an OIDC id-token for AWS role assumption.
• No additional imports, methods, or definitions are needed since this is a GitHub Actions YAML configuration change only.

In general, fix this by explicitly specifying permissions: for the workflow (and overriding per job if a job needs more than the minimal set). For jobs that only need to read repository contents and metadata, contents: read is sufficient; jobs that upload artifacts to the Actions storage do not need extra repo permissions beyond this. Only jobs that interact with issues, PRs, packages, etc. should request write scopes for those specific resources.

For this specific workflow, the simplest and least intrusive fix is to add a root-level permissions block that applies to all jobs, specifying a minimal, read-only configuration. From the visible code, the jobs shown (check-renv, no-renv-cache-used, renv-cache-available, update-renv-cache, record-cache-result) either call other actions, echo text, or upload an artifact. None of these require write access to repository contents. Therefore, adding at the top level:

permissions:
  contents: read

will constrain GITHUB_TOKEN appropriately without breaking existing behavior. We do not need to add job-specific permissions for renv-cache-available or record-cache-result; they will inherit the root permissions. The change should be inserted after the on: block (for clarity) and before concurrency: or jobs:. No new imports, methods, or other definitions are needed, since this is a YAML configuration change only.

To fix the problem, explicitly declare restricted permissions for the preflight job so it does not inherit broad repository defaults. Since preflight only runs checks and calls actions that read repository metadata, contents: read is sufficient and aligns with the CodeQL recommendation.

The best minimally invasive fix is:

• Add a permissions block under jobs.preflight with only contents: read.
• Leave the existing permissions blocks for full-build and update-container-version unchanged.
• Do not alter any steps, environment variables, or other job configuration.

Concretely, in .github/workflows/docker_build_deploy.yaml, edit the preflight job definition (around lines 44–57). Insert:

    permissions:
      contents: read

between runs-on: ubuntu-latest and outputs:. No imports or additional definitions are required, as this is pure workflow YAML.

In general, the fix is to explicitly declare minimal permissions for jobs so they don’t inherit broader repository defaults. For this workflow, the best approach is:

• Add a root-level permissions block that sets contents: read (a safe baseline for most workflows).
• Override that baseline for individual jobs:
  • preflight and check-renv do not need any token access, so set permissions: {} for those jobs to fully disable GITHUB_TOKEN.
  • Leave the existing permissions for update_cache unchanged, since it already declares explicit scopes including contents: write, pull-requests: write, etc.

This preserves existing functionality while tightening security for the jobs that don’t need token permissions and documenting a minimal baseline for the workflow. All changes are in .github/workflows/update-cache.yaml:

• Insert a root-level permissions: block after the on: definition and before env:.
• Add permissions: {} to the preflight and check-renv job definitions.

In general, the fix is to explicitly declare a permissions block in the workflow (at the top level or per-job) that grants only the minimal scopes required. If none of the jobs need to modify repository contents, issues, or pull requests, you can set contents: read at the workflow level. This both documents the intended access and prevents the workflow from accidentally inheriting broader write permissions from the repository or organization defaults.

For this specific workflow file .github/workflows/docker_apply_cache.yaml, the simplest and safest fix without changing functionality is to add a top-level permissions block right after the on: section. The jobs shown (including record-cache-result) only read workflow context, configure AWS credentials via OIDC, and upload an artifact. None of these operations require write access to repository contents, issues, or pull requests. Therefore, setting permissions: contents: read at the workflow root is appropriate and will apply to all jobs, including record-cache-result, unless any job overrides it. No additional imports or methods are required as this is purely a YAML configuration change.

Concretely:

• Edit .github/workflows/docker_apply_cache.yaml.
• After the on: block (after line 14), insert:

permissions:
  contents: read

• Keep indentation consistent with the existing top-level keys (name, description, on, concurrency, jobs).
• No other regions or files need to be altered.