Update 8hobbies/workflows digest to abd9589

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
8hobbies/workflows	action	digest	00e8456 -> abd9589

---

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 terms, the fix is to explicitly scope the GITHUB_TOKEN permissions in this workflow so it does not inherit possibly broad repository defaults. This is done by adding a permissions: block either at the top level (to apply to all jobs) or to the lint job specifically. For a lint workflow that only needs to clone code and run checks, contents: read is typically sufficient.

The single best minimal change without altering existing functionality is to add a root-level permissions: block between the on: section and the jobs: section in .github/workflows/lint.yml. This way, any current or future jobs in this workflow inherit the restricted permissions unless they explicitly override them. We’ll set:

permissions:
  contents: read

No imports or additional methods are needed because this is a pure YAML configuration change within the GitHub Actions workflow file.

Concretely:

• Edit .github/workflows/lint.yml.
• After line 21 (the last line of the on.pull_request.branches list) and before line 23 (jobs:), insert the permissions: block shown above.
• Leave the jobs.lint.uses line unchanged.

In general, fix this issue by adding an explicit permissions block either at the workflow root (applies to all jobs by default) or under the run job (applies only to that job). The minimal starting point is typically contents: read, which provides read-only access to the repository contents; if the reusable workflow requires more (for example, packages: write), those can be added as needed.

For this specific workflow, the least intrusive and clearest fix is to define a workflow-level permissions block right after the on: section. This will ensure that the run job – which calls the reusable workflow – executes with only the specified scopes for GITHUB_TOKEN. Because we don’t have visibility into the reusable workflow internals, we should select a conservative-yet-useful baseline such as:

permissions:
  contents: read

This preserves current behavior for most read-only operations while avoiding broad write privileges. If later the reusable workflow requires additional rights, they can be incrementally added. Concretely, in .github/workflows/publish-dry-run.yml, insert the permissions block between the on: definition (lines 17–21) and the jobs: key (line 23). No imports or other definitions are needed.

In general, the fix is to explicitly set a permissions block for the workflow or for the specific job so that the GITHUB_TOKEN has only the minimum required access. When using reusable workflows (jobs.<job_id>.uses), GitHub recommends declaring permissions in the caller workflow; these are then passed to the called workflow unless overridden.

For this file, the simplest and least disruptive fix is to add a root-level permissions block that applies to all jobs (including the test job using the reusable workflow). Since we do not know of any write operations being required from the snippet, we can safely set contents: read as a minimal starting point, which aligns with GitHub’s own recommended baseline. Concretely, in .github/workflows/runtime.yml, insert:

permissions:
  contents: read

between the on: block and the jobs: block (around line 23). This does not change any existing job configuration or behavior beyond tightening the default token permissions.