Update 8hobbies/workflows digest to 067ef9a

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
8hobbies/workflows	action	digest	593ea3e → 067ef9a

---

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 type of issue you add an explicit permissions block either at the top level of the workflow (applies to all jobs) or under the specific job. For a lint workflow that should not modify repository contents, a minimal contents: read is typically sufficient. This constrains the GITHUB_TOKEN to read-only access to the repo contents unless more is needed.

For this specific file, the simplest, non‑disruptive fix is to add a workflow‑wide permissions block right after the on: section and before jobs:. That keeps the reusable workflow call intact while ensuring any job that doesn’t override permissions (including this lint job) runs with only read access to repository contents. Unless the reusable workflow’s implementation requires broader permissions (which we’re not told and must not assume), contents: read is the safest choice aligned with least privilege.

Concretely:

• Edit .github/workflows/lint.yml.

• After line 21 (the last line of the on: section), insert:

  permissions:
    contents: read

No imports or additional methods are required, as this is pure YAML configuration.

To fix the problem, explicitly declare a permissions block so that the GITHUB_TOKEN is not implicitly given broad default scopes. Since this workflow’s single job only calls a reusable workflow and does not itself perform any repository‑modifying actions, a safe minimal starting point is to set top‑level permissions to read‑only for contents (and other scopes can be added later if required after testing).

The best way to do this without changing functionality is to add a top‑level permissions block (sibling of on: and jobs:) setting contents: read. This will apply to all jobs that don’t specify their own permissions, including the run job that calls the reusable workflow. If the reusable workflow requires more than read access, it should either (a) declare its own narrower permissions in that repository, or (b) you can later extend this block with the specific write scopes it needs. Concretely, in .github/workflows/publish-dry-run.yml, insert:

permissions:
  contents: read

between the on: block and the jobs: block. No imports or additional definitions are needed.

In general, the fix is to explicitly restrict the GITHUB_TOKEN permissions in the workflow to the minimum necessary, rather than relying on repository defaults. This is done by adding a permissions: block either at the top level of the workflow (applies to all jobs that don’t override it) or under the specific job.

For this workflow, the least invasive and clearest fix is to add a top-level permissions: block after the on: section, before jobs:. Since the workflow appears to just invoke a reusable workflow for runtime tests and does not itself need write access, we can safely set contents: read as a minimal, conservative default. If the reusable workflow requires additional scopes, they can still be requested there; setting read-only here will not unintentionally grant extra privileges. Concretely, in .github/workflows/runtime.yml, insert:

permissions:
  contents: read

between the on: block (lines 17–21) and the jobs: block (line 23). No imports or additional methods are needed; this is purely a YAML configuration change.