Update Workflows to Version 0.18.3

[fherreazcue]

🤖 This is an automated build

Update Workflows from sandpaper version 0.16.12 -> 0.18.3

• Auto-generated by create-pull-request on 2026-01-20T00:13+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 problem is fixed by explicitly defining a permissions block for the workflow (or the specific job) and scoping the GITHUB_TOKEN to the minimal rights required. For the preflight job, no token access is needed, so the safest option is to set default workflow permissions to contents: read, which is GitHub’s recommended minimal baseline and is sufficient for most basic operations while avoiding unnecessary write access. Jobs that require additional privileges can still override this with their own permissions blocks, as check-renv already does.

For this file, the best fix without changing existing functionality is:

• Add a top-level permissions: block near the top of the workflow, after the on: block (line 15/16 area), setting contents: read. This will apply to all jobs that do not explicitly specify permissions, including preflight, no-renv-cache-used, renv-cache-available, update-renv-cache, and trigger-build-deploy.
• Leave the existing permissions block in check-renv unchanged so it can still obtain id-token: write as required.
• No additional imports or dependencies are needed; this is purely a YAML configuration change.

Concretely, edit .github/workflows/docker_apply_cache.yaml to insert:

permissions:
  contents: read

between the on: block (lines 3–14) and the concurrency: section (lines 16–19). This ensures the preflight job (highlighted by CodeQL) now has an explicit, least-privilege permission set.

To fix the issue, explicitly set GitHub token permissions instead of relying on the repository defaults. For jobs that don’t need the token, you should disable it entirely with permissions: {} (or permissions: read-all if you prefer a minimal read access). This enforces least privilege and satisfies CodeQL’s requirement for an explicit permissions block.

The best fix here without changing functionality is:

• Add a root‑level permissions: block near the top of .github/workflows/docker_apply_cache.yaml to define safe defaults for all jobs (e.g., read-all).
• For the no-renv-cache-used job specifically (line 62), add permissions: {} to disable the token for that job, overriding the workflow default.
• Optionally, other trivial jobs like renv-cache-available and preflight can also get permissions: {}, but CodeQL’s reported location is no-renv-cache-used, so we’ll minimally ensure that job is explicitly configured.

No new imports, methods, or external definitions are needed; this is purely a YAML workflow configuration change within .github/workflows/docker_apply_cache.yaml.

In general, each job should have an explicit permissions block (or inherit from a restrictive root-level permissions block) that grants only the minimal rights needed. For jobs that do not need to call GitHub’s API or modify repository resources, you can set permissions: {} (no permissions) or permissions: contents: read if read access is required.

For this specific workflow:

• The renv-cache-available job only prints a message via run: echo, so it does not need any token permissions. The safest fix is to add permissions: {} to that job.
• This change stays within the shown snippet and does not alter existing functionality, as the job does not rely on GITHUB_TOKEN or GitHub API access.
• Concretely, in .github/workflows/docker_apply_cache.yaml, locate the renv-cache-available job definition starting at line 70. Insert a permissions: {} line (properly indented) after runs-on: ubuntu-latest (line 72) and before needs: check-renv (line 73).

No additional methods, imports, or definitions are required: it is purely a YAML configuration change.

In general, the fix is to add an explicit permissions block to the workflow (at the top level, or per‑job) so that GITHUB_TOKEN is limited to the minimal scopes required. This prevents the workflow from silently inheriting broader repository/organization defaults.

For this workflow, no steps modify repository contents or manage issues/PRs; they mainly read repo metadata, configure AWS via OIDC, upload to S3, and trigger another workflow using gh workflow run. The safe, minimal practical set is to define a root‑level permissions block with contents: read and actions: write (needed so gh workflow run can dispatch another workflow). We can set this once near the top of .github/workflows/docker_apply_cache.yaml (e.g., after on: or after concurrency:), and it will apply to all jobs, including trigger-build-deploy, without changing any existing behavior.

Concretely:

• Edit .github/workflows/docker_apply_cache.yaml.
• Insert a top‑level permissions: block, aligned with on: and jobs:.
• Use:

  permissions:
    contents: read
    actions: write

• No additional imports or methods are needed; this is purely a workflow configuration change.

In general, to fix this class of issue you explicitly define a permissions block either at the workflow level or per job, granting only the capabilities that job truly needs. This prevents GitHub from falling back to broader, repository-level defaults and reduces the blast radius of any compromised GITHUB_TOKEN.

For this specific workflow, the best minimally invasive change is to add a permissions block to the preflight job only. The other jobs (full-build and update-container-version) already declare explicit permissions, so no change is needed there. The preflight job appears to only need to read repository contents and metadata, so we can set permissions: contents: read. This satisfies CodeQL’s recommendation and adheres to least privilege without altering functionality.

Concretely:

• Edit .github/workflows/docker_build_deploy.yaml.
• Under jobs: preflight: ... runs-on: ubuntu-latest, insert:

    permissions:
      contents: read

• Keep indentation aligned with runs-on: and env: in that job.
• No additional methods, imports, or external dependencies are required.

In general, the problem is fixed by explicitly adding a permissions: section to the workflow or to the individual jobs so the GITHUB_TOKEN has only the minimal rights required. Jobs that only need to read repository contents can use permissions: contents: read (or even permissions: read-all); jobs that need to open PRs or push code can request specific write scopes as already done for update_cache.

For this workflow, the safest, non‑breaking approach is:

• Add a workflow-level permissions block near the top (after description: or on:) that sets everything to read-only with contents: read. This will apply to all jobs by default.
• Keep the existing job-level permissions on update_cache to override the default, since it already correctly grants specific write scopes.
• Do not change job logic or steps; only add the permissions declaration.

Concretely:

• Edit .github/workflows/update-cache.yaml.

• Insert:

  permissions:
    contents: read

  after the description: line (or before on:), so preflight and check-renv will run with contents: read and no broader write access, while update_cache retains its explicit, more permissive block.

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