chore(github): update the shared workflow actions to their current majors

[bwp91]

Brings the actions used by the shared workflows up to their current major versions. Several were a major behind, and create-pull-request was two.

Worth noting: the plugin repos were already on actions/checkout@v7 and actions/setup-node@v7 in their own workflows, so the shared workflows had drifted behind the repos that call them, and the org was effectively running two versions side by side.

What changed

Action	From	To	Workflows
actions/checkout	v6	v7	17 uses across 16 workflows
actions/setup-node	v6	v7	10 uses across 10 workflows
actions/stale	v10	v11	stale.yml
actions/labeler	v6	v7	labeler.yml
release-drafter/release-drafter	v6	v7	release-drafter.yml
peter-evans/create-pull-request	v6	v8	promote-branch.yml

On the breaking changes

I read the release notes for each major rather than bumping blind:

• stale v11 and labeler v7 are ESM migrations plus dependency updates. No input or config changes.
• create-pull-request v8 requires Actions Runner v2.327.1 or later only on self-hosted runners. Every job here runs on ubuntu-latest, so it does not apply — I checked, there are no self-hosted runners in this repo.
• release-drafter v7 is the only one needing a real edit. It introduces a token input that replaces the GITHUB_TOKEN env var the action used to read, so release-drafter.yml now passes the secret as an input rather than an env var. Everything else about that workflow is unchanged.

Nothing else needed adjusting — no input names, defaults or behaviour changed in the rest.

Everything already current, for completeness

actions/upload-artifact@v7, actions/download-artifact@v8, github/codeql-action@v4, coverallsapp/github-action@v2, softprops/action-gh-release@v3, viperproject/create-nightly-release@v2, sarisia/actions-status-discord@v1, martinbeentjes/npm-get-version-action@v1.3.1, peter-evans/create-issue-from-file@v6, dropseed/changerelease@v1, TriPSs/conventional-changelog-action@v6, TimonVS/pr-labeler-action@v5.

Testing

These are reusable workflows, so the real proof is the first run of each caller. The two with the widest blast radius are eslint.yml and nodejs-build-and-test.yml, which every @homebridge-plugins repo now calls — those will exercise checkout@v7 and setup-node@v7 immediately.

The riskiest by scope is promote-branch.yml, since it is the least frequently run and jumps two majors. Worth a deliberate look the first time it fires.

[Copilot]

Pull request overview

This PR updates the GitHub Actions used by this org’s reusable workflows to newer major versions (primarily actions/checkout@v7 and actions/setup-node@v7), and adjusts release-drafter usage for its v7 input changes.

Changes:

• Bump actions/checkout from v6 → v7 across multiple reusable workflows.
• Bump actions/setup-node from v6 → v7 across the Node-based reusable workflows.
• Update other workflow actions to new majors (actions/stale@v11, actions/labeler@v7, release-drafter@v7, create-pull-request@v8), including the release-drafter token input migration.

Reviewed changes

Copilot reviewed 19 out of 19 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
.github/workflows/update-version.yml	Bumps actions/checkout to v7 for the version update reusable workflow.
.github/workflows/update-beta-version.yml	Bumps checkout/setup-node to v7 in the beta version update workflow.
.github/workflows/sync-github-release.yml	Bumps actions/checkout to v7 before generating/updating GitHub releases.
.github/workflows/stale.yml	Bumps actions/stale to v11.
.github/workflows/release-drafter.yml	Bumps release-drafter to v7 and passes the token via with: token.
.github/workflows/publish-release.yml	Bumps checkout/setup-node to v7 in publish/release reusable workflow jobs.
.github/workflows/promote-branch.yml	Bumps checkout to v7 and create-pull-request to v8 for promotion PR automation.
.github/workflows/pre-release.yml	Bumps actions/checkout to v7 for the prerelease workflow.
.github/workflows/npm-publish.yml	Bumps checkout/setup-node to v7 for npm publishing (token-based).
.github/workflows/npm-publish-oidc.yml	Bumps checkout/setup-node to v7 for npm publishing (OIDC).
.github/workflows/npm-publish-esm.yml	Bumps checkout/setup-node to v7 for ESM npm publishing (token-based).
.github/workflows/npm-publish-esm-oidc.yml	Bumps checkout/setup-node to v7 for ESM npm publishing (OIDC).
.github/workflows/nodejs-build-and-test.yml	Bumps checkout/setup-node to v7 in the shared CI workflow.
.github/workflows/lint-docs.yml	Bumps checkout/setup-node to v7 in the TypeDoc lint workflow.
.github/workflows/labeler.yml	Bumps actions/labeler to v7.
.github/workflows/homebridge-beta-bot.yml	Bumps checkout/setup-node to v7 in the beta bot workflow.
.github/workflows/eslint.yml	Bumps checkout/setup-node to v7 in the shared ESLint workflow.
.github/workflows/determine-release-type.yml	Bumps actions/checkout to v7 in release-type determination.
.github/workflows/codeql-analysis.yml	Bumps actions/checkout to v7 for CodeQL analysis workflow.

[bwp91]

Good catch on the scope — that one was a genuine miss on my part.

I globbed .github/workflows/ only, which skipped two reusable workflows that live elsewhere:

• .github/auto-release.yml
• sharedWorkflows/homebridge-dependency-bot.yml

Both are workflow_call workflows and both were still on actions/checkout@v6 and actions/setup-node@v6. Now bumped, and grep confirms no @v6 references remain anywhere in the repository. Thanks — the PR description was overclaiming before this.

I checked the other actions in auto-release.yml while I was there: phips28/gh-action-bump-version@v11, conventional-changelog/standard-version@v9 and softprops/action-gh-release@v3 are all on their current majors.

On the two token comments — both are fair, and both describe behaviour that predates this PR rather than anything it introduces:

• stale.yml passes repo-token: ${{ secrets.token }} while declaring the secret optional, so a caller that omits it sends an empty value.
• labeler.yml declares a token secret that nothing reads, using secrets.GITHUB_TOKEN instead.

Both look like real bugs and the fix in each case is a fallback to github.token. I have deliberately left them out of this PR: it is a version bump across 21 workflows, and changing token handling affects every repository in the org, so it deserves its own change where it can be reviewed on its own terms rather than buried in a bump. Raising them separately.

[bwp91]

Raised the two token issues separately as #50, so they can be reviewed on their own rather than inside a version bump.

While writing it I audited every workflow here that declares a token secret, and found a third, milder instance: nodejs-build-and-test.yml reads secrets.github_token in its Coveralls parallel step but secrets.token in the finished step. Only one of those is the declared secret. It is inert unless coverage is enabled, and it is left out of #50 because #49 already modifies that file and the two would conflict.

[Copilot]

Pull request overview

Copilot reviewed 21 out of 21 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

.github/workflows/stale.yml:35

• secrets.token is declared as optional for this reusable workflow, but it’s always used as repo-token. If the caller doesn’t pass the secret, this will evaluate to an empty string and the stale action will fail authentication. Either make the secret required or fall back to the built-in github.token when it’s not provided.

      - uses: actions/stale@v11
        with:
          repo-token: ${{ secrets.token }}

.github/workflows/promote-branch.yml:22

• This workflow uses secrets.GITHUB_TOKEN to create a pull request, but it doesn’t declare any permissions. With GitHub’s increasingly common read-only default token permissions, create-pull-request can fail unless the caller sets write permissions. Setting explicit job permissions here makes the reusable workflow self-contained and less brittle.

    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0

.github/workflows/release-drafter.yml:14

• release-drafter needs write access to repository contents (and typically read access to PRs) when using GITHUB_TOKEN. This reusable workflow doesn’t declare permissions, so it relies on the caller/repo defaults and may break under read-only defaults. Adding explicit permissions here prevents surprising failures when upgrading action majors.

  update_release_draft:
    runs-on: ubuntu-latest
    steps:
      - uses: release-drafter/release-drafter@v7