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.

To fix the problem, explicitly declare the permissions for the GITHUB_TOKEN either at the workflow root (applies to all jobs) or on the lint job itself. For a standard lint workflow that only needs to read the repository to run checks, the least‑privilege baseline is contents: read. Since this workflow delegates to a reusable workflow and we cannot see its internals, we should still choose the minimal safe default of read‑only contents, which matches GitHub’s recommended starting point for many CI workflows.

The single best fix with minimal functional impact is to add a root‑level permissions block just below the on: section (or just above jobs:), specifying contents: read. This will apply to all jobs in this workflow, including lint, unless overridden. Concretely, in .github/workflows/lint.yml, add:

permissions:
  contents: read

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

To fix the problem, define an explicit permissions: block so that the GITHUB_TOKEN used by this workflow is restricted to the minimal required scopes. Since we cannot see the internals of 8hobbies/workflows/.github/workflows/npm-publish-dry-run.yml, the safest non-breaking change is to set permissions: read-all at the workflow level. This mirrors the typical read-only default while avoiding unintentionally revoking write permissions that the reusable workflow may rely on. If you later audit the reusable workflow and determine it needs less, you can replace read-all with a narrower set, e.g. contents: read or contents: read plus any specific write scopes needed.

Concretely, in .github/workflows/publish-dry-run.yml, add a root-level permissions: section between the on: block and the jobs: block. No imports or additional methods are needed; this is purely a YAML configuration change. For example, insert:

permissions:
  contents: read

if you know only read access to repository contents is needed, or:

permissions: read-all

as a conservative, generally safe least-privilege starting point compared with possible read-write defaults. This change preserves existing behavior of the reusable workflow while ensuring the workflow is no longer dependent on repository or organization defaults for GITHUB_TOKEN permissions.

To fix the problem, explicitly limit the GITHUB_TOKEN permissions in this workflow to the minimum needed. Since we cannot see what operations are required by the reusable workflow, the safest generic baseline is read-only access to repository contents (contents: read). This documents the intended permissions and ensures the workflow remains least-privilege even if repository or organization defaults change later or the workflow is reused elsewhere.

The single best way to fix this without changing existing functionality is to add a permissions: block at the workflow root level (between on: and jobs:) so it applies to all jobs that do not override permissions. In .github/workflows/runtime.yml, insert:

permissions:
  contents: read

after the on: block (after line 21 in the provided snippet). This does not alter the job definition or the uses: reference and merely constrains what the GITHUB_TOKEN can do. No additional imports, methods, or definitions are required for a YAML workflow; GitHub Actions understands the permissions key natively.