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:41+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, to fix this type of issue you explicitly declare a permissions block either at the workflow root (applies to all jobs without their own block) or on each job, and reduce the GITHUB_TOKEN privileges to the minimum needed (often contents: read, or {} if no API access is required).

For this workflow, the preflight job only evaluates event context and writes to GITHUB_OUTPUT; it doesn’t use GITHUB_TOKEN, call GitHub APIs, or check out the repo. The safest and least-privilege fix without changing functionality is to add a permissions block to that job and set it to an empty mapping, which disables all default permissions for that job. Other jobs already have their own permissions where needed (e.g., check-renv has id-token: write), so we only change preflight.

Concretely:

• Edit .github/workflows/docker_apply_cache.yaml.
• Within the preflight job definition, between runs-on: ubuntu-latest (line 24) and outputs: (line 25), add:

      permissions: {}

This leaves functionality unchanged while explicitly restricting the job’s token permissions.

In general, the fix is to add an explicit permissions block to the workflow or to each job, restricting the GITHUB_TOKEN to the minimal scopes required. Jobs that do not interact with the repository or GitHub APIs can use permissions: { contents: read } as a safe, minimal baseline; jobs that need elevated permissions (like id-token: write for OIDC) should declare only those.

For this workflow, the simplest and least-disruptive change is to add a root-level permissions block (applies to all jobs) that sets contents: read. This satisfies CodeQL for jobs such as no-renv-cache-used, renv-cache-available, update-renv-cache, and record-cache-result, which only echo, run external actions, or upload artifacts and do not require repository writes. The existing check-renv job already has a permissions block with id-token: write; per GitHub’s rules, a job-level permissions block overrides the workflow default, so we should keep that intact and only add the new workflow-level permissions above jobs:.

Concretely:

• In .github/workflows/docker_apply_cache.yaml, insert a root-level permissions: section (e.g., after the concurrency block) with contents: read.
• Do not modify existing job definitions or the check-renv job’s permissions block, as it already expresses its special requirement.

No new imports or methods are needed; this is purely a YAML workflow configuration change.

In general, this problem is fixed by explicitly defining a permissions block that restricts the default GITHUB_TOKEN privileges, either at the workflow root (affecting all jobs) or per-job. For a job that does not need to access the GitHub API at all, we can safely set permissions: {} (or an explicit mapping with only contents: read if some read access is needed). This documents the intended permissions and protects the workflow if repository/organization defaults are permissive.

The single best fix here, without changing any existing behavior, is to add a minimal permissions block to the renv-cache-available job, because that is the job CodeQL flagged. Since the only step in that job is a simple run: echo "renv cache available for this lesson", it does not need the GITHUB_TOKEN at all, so we can completely disable token permissions for that job using an empty permissions map. Concretely, in .github/workflows/docker_apply_cache.yaml, under the renv-cache-available job (around lines 70–77), insert a permissions: {} line at the same indentation level as runs-on, needs, and if. No additional imports, methods, or external definitions are needed; this is purely a YAML configuration change.

To fix this, explicitly declare a permissions block so that the preflight job does not inherit broad default repository/organization permissions. The least-privilege baseline for jobs that only need to read repository contents (for example, for preflight checks and determining container versions) is contents: read. Because this job already passes secrets.GITHUB_TOKEN into actions and does not appear to push commits, create releases, or modify issues/PRs, there is no indication it requires any write scopes.

The best minimal change without altering functionality is to add a permissions block under the preflight job definition. Concretely, in .github/workflows/docker_build_deploy.yaml, immediately under runs-on: ubuntu-latest for the preflight job, add:

    permissions:
      contents: read

This constrains only that job’s GITHUB_TOKEN while leaving the existing, more permissive permissions blocks for the full-build and update-container-version jobs unchanged. No imports or additional methods are needed; this is a pure workflow YAML configuration change.

In general, the problem is fixed by adding an explicit permissions block that restricts the GITHUB_TOKEN to the minimal scopes required. This can be done at the workflow root (applies to all jobs that don’t override it) or per job. Here, we already have an explicit permissions block for the update_cache job; the preflight and check-renv jobs don’t need write access and can safely run with read-only repository access. The cleanest fix is to add a root-level permissions block with read-only contents (and no other scopes), which will apply to preflight and check-renv while leaving the existing permissions on update_cache unchanged.

Concretely:

• Add a new permissions: section near the top of .github/workflows/update-cache.yaml, at the workflow root level (same indentation as name, description, on, env, jobs).
• Set it to contents: read, which is the minimal common read-only permission equivalent to a read-only default and sufficient for basic operations that might require token-based repository access (and harmless if unused).
• Keep the existing permissions block under update_cache as-is; per GitHub’s semantics, job-level permissions override the workflow default, so update_cache retains its broader rights, while preflight (the line CodeQL flagged) and check-renv now have explicit, limited permissions.

No imports or external dependencies are involved; this is a pure YAML configuration change confined to .github/workflows/update-cache.yaml.

In general, the fix is to add an explicit permissions block either at the top level of the workflow (to apply to all jobs) or specifically to the record-cache-result job, granting only the minimal scopes required (likely just contents: read for actions metadata and artifact upload). This restricts the GITHUB_TOKEN so it cannot perform unintended write operations even if the repository default is permissive.

The safest, least‑intrusive fix here is to add a root‑level permissions block right after the on: section, setting contents: read. None of the shown jobs appears to need to write to the repository, open issues, or modify pull requests; the AWS access for S3 uses OIDC and the AWS role, not GITHUB_TOKEN. actions/upload-artifact does not require write access to repo contents; it interacts with GitHub’s artifact service. Therefore, contents: read at the workflow root is a good minimal baseline and should not change existing behavior.

Concretely, in .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 16). This will apply to all jobs, including record-cache-result, satisfying the CodeQL requirement and aligning with least‑privilege principles without changing workflow functionality.