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, this problem is fixed by explicitly declaring a permissions block either at the root of the workflow (to apply to all jobs) or inside the specific job that uses the GITHUB_TOKEN. For a lint workflow that only needs to fetch code and run checks, contents: read is typically sufficient. This constrains GITHUB_TOKEN to read-only access to repository contents, rather than inheriting potentially broader read-write defaults.

The single best fix here, without changing functionality, is to add a root-level permissions block just after the name: line (or before jobs:) in .github/workflows/lint.yml, specifying contents: read. A root-level block will apply to the lint job unless that job or the called reusable workflow requests narrower permissions. Since this workflow appears only to run linting via a reusable workflow, read-only repository contents access is appropriate and should not break existing behavior.

Concretely:

• Edit .github/workflows/lint.yml.

• Insert:

  permissions:
    contents: read

  between the name: Lint line and the on: block. No imports or additional methods are needed, as this is pure YAML configuration.

Generally, the fix is to add an explicit permissions block that limits the default GITHUB_TOKEN scope to the minimum required. This can be declared either at the workflow root (applies to all jobs) or under the specific job. Since this workflow only has a single run job and delegates to another workflow, the cleanest approach is to set permissions at the workflow root so any future jobs also inherit restricted permissions by default.

Concretely, in .github/workflows/publish-dry-run.yml, insert a permissions: section between the name: and on: keys. For a publish dry run that should only need to read repository contents and metadata for dependency installation and tests, contents: read is a safe starting point. If the called workflow truly needs broader permissions (e.g., to write to packages or create releases), those can be further specialized in the called workflow itself; the local workflow does not need to grant write permissions unless explicitly required. No imports or additional methods are necessary because this is a YAML configuration file.

To fix the problem, explicitly set permissions for the workflow or for the test job so that the GITHUB_TOKEN has only the minimal required scopes. Since this file triggers tests on push and pull_request and delegates all work to a reusable workflow, the safest and simplest approach is to set a restrictive default at the workflow root, which applies to all jobs that do not override it.

The single best fix without changing functionality is to add a root-level permissions: block with contents: read, which is a common minimal starting point for CI workflows that only need to read the repository. If the reusable workflow requires additional scopes (e.g., packages: read), those would be added there as needed, but we cannot infer that from the snippet, so we stick to a minimal yet standard configuration. Concretely, in .github/workflows/runtime.yml, add a permissions: section after the on: block and before jobs:. No imports or additional definitions are needed because this is a YAML workflow configuration change only.