[claude]

Requested by Keeley Hammond · Slack thread

The release action pinned here ran the npm publish step on Node 24.10.0, which predates the October 2026 Node.js security release. v1.1.2 tracks the latest Node 24.x via check-latest, so future Node patch releases need no further pin bumps.

---

Generated by Claude Code

[claude]

I reviewed this PR and didn't find any bugs. The bumped action runs in the npm-trusted-publisher job with id-token: write, and I couldn't confirm from this checkout that the new SHA matches upstream v1.1.1, so a human should still check it.

What was reviewed:

• The only change is the pin for electron/semantic-trusted-release on line 39 of .github/workflows/release.yml. It is still a full 40-character SHA from the electron org, with a # v1.1.1 comment like the other actions in the file.
• The step's inputs (github-token from the secret-service output) and the job's permissions are unchanged.
• Still open: whether 2a7b16df83a1f77339ad473654c5fbd2b32b193b is the upstream v1.1.1 tag commit, and whether the diff from v1.1.0 is only the Node 24.22.1 update. I had no network access to look it up.

Extended reasoning...

The change edits one line in .github/workflows/release.yml, moving the pinned commit of electron/semantic-trusted-release from v1.1.0 to v1.1.1 without changing its inputs or permissions. This is a supply-chain surface: the action publishes to npm through OIDC (id-token: write, npm-trusted-publisher environment) and receives a GitHub App token. I couldn't check the new SHA against the upstream tag from the shallow, offline checkout. CODEOWNERS assigns every path in this repo to the electron/wg-ecosystem team, so I deferred instead of approving.

[claude]

I reviewed the latest push and didn't find any bugs. It's still worth having a code owner confirm that the new pin is the real upstream v1.1.2 commit before merging, because this action publishes to npm with a privileged token.

What was reviewed:

• The one-line change in .github/workflows/release.yml moves electron/semantic-trusted-release from 03517840… (v1.1.0) to 672a62fe… (v1.1.2). It keeps the full-SHA pin with a version comment, and the step inputs are unchanged.
• I couldn't check from this checkout that 672a62fe17fce21a0d10de5a6825ee54817af317 is the commit tagged v1.1.2 upstream.
• The PR title and description still say v1.1.1 and Node 24.22.1, but the latest commit pins v1.1.2. Updating them would keep the release history accurate.

Extended reasoning...

The change touches one line in the release workflow and updates the pinned SHA of the semantic-trusted-release action, the step that runs the npm publish with a GitHub token from the secret-service step. It is a supply-chain-sensitive surface: whatever code sits at the pinned SHA runs with publish credentials. CODEOWNERS assigns every path, including this workflow, to a code-owner team. The SHA-to-tag mapping could not be checked from this shallow checkout. A new commit (v1.1.1 to v1.1.2) has landed since the earlier review on this PR, and the PR text was not updated to match it.

[claude]

CI note: Test (22.23.4) failed (and required-ci with it, since it only aggregates the test job).

Root cause: four makeUniversalApp specs couldn't download the Electron zip from GitHub. @electron/get hit ConnectTimeoutError: Connect Timeout Error (attempted address: github.com:443, timeout: 10000ms) on the runner, and the follow-on "Obsolete snapshots found" error comes from those same four specs not running to completion. The other 59 tests passed.

Unrelated to this PR: the only change here is the pinned SHA in .github/workflows/release.yml, which runs on release/push and not in the Test workflow. The same job passed on this PR's previous head (https://github.com/electron/universal/actions/runs/39720986299/job/119634106891) and on main's latest push (https://github.com/electron/universal/actions/runs/39726814544/job/119652493112).

Fix: none needed in the repo. This was a transient network timeout, so re-running the failed job should clear it.

---

Generated by Claude Code

[MarshallOfSound]

Bypass merge via Orbital by @MarshallOfSound.

"behind base branch" should not block

This merge bypassed required checks / rules; the reason above was recorded first.