Update 8hobbies/workflows digest to 816c71c

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
8hobbies/workflows	action	digest	ad34dcf → 816c71c

---

Configuration

📅 Schedule: Branch creation - "on Sunday" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

In general, to fix this kind of issue, you add a permissions: block either at the top level of the workflow (to apply to all jobs) or under the specific job, specifying the minimal GITHUB_TOKEN scopes needed. For a lint job that only needs to read the repository to run lint checks, contents: read is typically sufficient; if it needs to read from GitHub Packages, packages: read can also be included.

For this specific workflow, we should add a root‑level permissions block just below the name: (or above jobs:) to document and enforce least privilege across all jobs (currently just lint). Since the job is a reusable workflow invocation and there is no evidence it needs write access, we will set contents: read. This does not change any functional behavior other than restricting any unintended write capabilities of GITHUB_TOKEN. No imports or additional methods are needed, as this is purely a YAML configuration change in .github/workflows/lint.yml.

Concretely:

• Edit .github/workflows/lint.yml.

• Insert:

  permissions:
    contents: read

  between the on: block and the jobs: block (or just after name: Lint and before on:; both are valid, but placing it after on: keeps the structure clear).

• Leave the existing jobs.lint.uses line unchanged.

In general, the problem is fixed by adding an explicit permissions block that grants only the minimum required scopes for the workflow, either at the top level (applies to all jobs) or within the specific job. For a publish dry-run workflow that runs a reusable workflow and typically only needs to read repository contents, starting with contents: read at the workflow level is a safe least-privilege default unless additional scopes are clearly required.

For this specific file, the best fix without changing functionality is to add a top-level permissions block after the on: section and before jobs:. Since the shown workflow only calls a reusable workflow and we have no evidence it needs write access from this caller, we will restrict GITHUB_TOKEN to contents: read, which is the minimal common setting and matches GitHub’s recommended baseline. If the reusable workflow requires more permissions, they can be granted within that reusable workflow itself, keeping this entrypoint conservative.

Concretely, in .github/workflows/publish-dry-run.yml, insert:

permissions:
  contents: read

between the on: block (lines 17–21) and the jobs: key (line 23). No imports or additional definitions are needed.

Generally, the fix is to add an explicit permissions block that grants only the minimal required scopes to GITHUB_TOKEN. This can be set at the workflow root (applies to all jobs unless overridden) or at the job level. Since we are not changing functionality and do not know the exact needs of the reusable workflow, the safest minimal baseline matching GitHub’s read-only default is:

permissions:
  contents: read

This documents that the workflow only expects read access to repository contents unless further scopes are added later.

The best minimally invasive fix here is to add a root-level permissions block just after the on: section (before jobs:) in .github/workflows/runtime.yml. This will apply to the test job that calls the reusable workflow without altering the structure or behavior of the workflow, other than potentially reducing unnecessary write privileges. No imports or additional definitions are required; it is a pure YAML configuration change within this file.