Update 8hobbies/workflows digest to d1e85a0

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
8hobbies/workflows	action	digest	b912c36 → d1e85a0

---

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 adding a permissions block either at the root of the workflow (applies to all jobs without their own permissions) or at the specific job level, and setting the least privileges needed. For a lint workflow that only needs to read source code and dependencies, contents: read (and optionally other read-only scopes like packages: read if required) is typically sufficient.

The minimal, least-privilege change here is to add a top-level permissions: block below the on: section in .github/workflows/lint.yml. This will apply to the lint job (which uses a reusable workflow) unless that reusable workflow further restricts permissions. No existing functionality in this file changes, because the job definition (uses: 8hobbies/workflows/.github/workflows/npm-lint.yml@...) remains untouched; we only constrain the GITHUB_TOKEN. Concretely, update .github/workflows/lint.yml by inserting:

permissions:
  contents: read

at the root level, aligned with name, on, and jobs. No imports, methods, or additional definitions are required beyond that YAML addition.

In general, to fix this class of issue you add a permissions key either at the top level of the workflow (to apply to all jobs) or inside a specific job (to apply only to that job). The values under permissions should be the minimum scopes required, typically starting with contents: read and adding any necessary write scopes only if the workflow actually needs them.

For this specific workflow, we should add a top-level permissions block so that it applies to the single run job that calls the reusable workflow. Because we don’t see any other requirements in this file, and we must avoid assuming extra behavior, we will set the minimal commonly safe baseline: contents: read. This matches GitHub’s recommended starting point for most workflows and strictly limits GITHUB_TOKEN compared to a potential default of full read-write. Concretely, in .github/workflows/publish-dry-run.yml we’ll insert:

permissions:
  contents: read

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

In general, the fix is to explicitly declare permissions for the GITHUB_TOKEN either at the root of the workflow (applying to all jobs) or within the specific job. This avoids inheriting broad default permissions from the repository or organization and documents the minimal access needed. For a workflow whose only job delegates to a reusable workflow, a safe starting point is permissions: contents: read, which matches GitHub’s recommended minimal default for read-only access.

For this file, the most targeted fix without changing functionality is to add a permissions block at the workflow root, just below the on: block and above jobs:. Since we cannot see any operations here that require write access (the actual logic lives in the referenced reusable workflow), the least-privilege reasonable default is:

permissions:
  contents: read

This ensures the top-level workflow’s GITHUB_TOKEN has only read access to repository contents, while still allowing the workflow to run and call the reusable workflow. If the reusable workflow itself needs additional scopes, it can define them internally; setting minimal permissions here does not prevent that, as reusable workflows can request additional permissions they require.

Concretely:

• Edit .github/workflows/runtime.yml.
• Insert a permissions: mapping between the on: block (lines 17–21) and the jobs: block (line 23).
• No imports or other definitions are needed; this is purely a YAML configuration change in the workflow file.