chore(deps): bump pnpm/action-setup from 4 to 5#311
chore(deps): bump pnpm/action-setup from 4 to 5#311dependabot[bot] wants to merge 1 commit intomainfrom
Conversation
Bumps [pnpm/action-setup](https://github.com/pnpm/action-setup) from 4 to 5. - [Release notes](https://github.com/pnpm/action-setup/releases) - [Commits](pnpm/action-setup@v4...v5) --- updated-dependencies: - dependency-name: pnpm/action-setup dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
Greptile SummaryThis is a routine Dependabot PR that bumps
Confidence Score: 5/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["pnpm/action-setup@v4\n(SHA: 41ff726...)"] -->|bumped to| B["pnpm/action-setup@v5\n(SHA: fc06bc1...)"]
B --> C{Comment updated?}
C -->|Yes| D["ci.yml → # v5.0.0\ndeploy-docs.yml → @v5 tag"]
C -->|No — stale # v4| E["bundle-analysis.yml\ndocs-check.yml\ndocs-seo-aeo.yml\nprepare-release.yml\nrelease-on-tag.yml\nrelease.yml ×2\nstable-release.yml"]
E -.->|SHA still correct| F["✅ Functionally safe"]
D --> F
Prompt To Fix All With AIThis is a comment left during a code review.
Path: .github/workflows/bundle-analysis.yml
Line: 31
Comment:
**Stale version comments after bump to v5**
The SHA `fc06bc1257f339d1d5d8b3a19a8cae5388b55320` correctly points to `pnpm/action-setup` v5.0.0 (confirmed by `ci.yml` which correctly annotates it as `# v5.0.0`), but the inline comment here still reads `# v4`. This will mislead anyone auditing pinned action versions.
The same stale `# v4` comment appears in:
- `.github/workflows/bundle-analysis.yml:31`
- `.github/workflows/docs-check.yml:65`
- `.github/workflows/docs-seo-aeo.yml` (Setup pnpm step)
- `.github/workflows/prepare-release.yml` (Setup pnpm step)
- `.github/workflows/release-on-tag.yml` (Setup pnpm step)
- `.github/workflows/release.yml` (both Setup pnpm steps)
- `.github/workflows/stable-release.yml` (Setup pnpm step)
Only `ci.yml` (updated to `# v5.0.0`) and `deploy-docs.yml` (uses the floating `@v5` tag) are correct.
```suggestion
uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v5
```
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "chore(deps): bump pnpm/action-setup from..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| - name: Setup pnpm | ||
| uses: pnpm/action-setup@41ff72655975bd51cab0327fa583b6e92b6d3061 # v4 | ||
| uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4 |
There was a problem hiding this comment.
The SHA fc06bc1257f339d1d5d8b3a19a8cae5388b55320 correctly points to pnpm/action-setup v5.0.0 (confirmed by ci.yml which correctly annotates it as # v5.0.0), but the inline comment here still reads # v4. This will mislead anyone auditing pinned action versions.
The same stale # v4 comment appears in:
.github/workflows/bundle-analysis.yml:31.github/workflows/docs-check.yml:65.github/workflows/docs-seo-aeo.yml(Setup pnpm step).github/workflows/prepare-release.yml(Setup pnpm step).github/workflows/release-on-tag.yml(Setup pnpm step).github/workflows/release.yml(both Setup pnpm steps).github/workflows/stable-release.yml(Setup pnpm step)
Only ci.yml (updated to # v5.0.0) and deploy-docs.yml (uses the floating @v5 tag) are correct.
| uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4 | |
| uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v5 |
Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/workflows/bundle-analysis.yml
Line: 31
Comment:
**Stale version comments after bump to v5**
The SHA `fc06bc1257f339d1d5d8b3a19a8cae5388b55320` correctly points to `pnpm/action-setup` v5.0.0 (confirmed by `ci.yml` which correctly annotates it as `# v5.0.0`), but the inline comment here still reads `# v4`. This will mislead anyone auditing pinned action versions.
The same stale `# v4` comment appears in:
- `.github/workflows/bundle-analysis.yml:31`
- `.github/workflows/docs-check.yml:65`
- `.github/workflows/docs-seo-aeo.yml` (Setup pnpm step)
- `.github/workflows/prepare-release.yml` (Setup pnpm step)
- `.github/workflows/release-on-tag.yml` (Setup pnpm step)
- `.github/workflows/release.yml` (both Setup pnpm steps)
- `.github/workflows/stable-release.yml` (Setup pnpm step)
Only `ci.yml` (updated to `# v5.0.0`) and `deploy-docs.yml` (uses the floating `@v5` tag) are correct.
```suggestion
uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v5
```
How can I resolve this? If you propose a fix, please make it concise.![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — the SHA correctly points to pnpm/action-setup v5.0.0; the inline comments flag the stale # v4 annotations and the pre-existing mutable-tag issue in deploy-docs.yml.
Extended reasoning...
Overview
This Dependabot PR updates pnpm/action-setup from v4 to v5 across 9 workflow files by replacing the old SHA with the new SHA for v5.0.0. The change is purely mechanical — no logic, permissions, or workflow structure is altered.
Security risks
The SHA swap is the correct supply-chain-safe mechanism; the new SHA is the immutable v5.0.0 commit. The pre-existing mutable-tag usage in deploy-docs.yml (flagged by the inline comment) was already present before this PR and is a separate concern. No new security regressions are introduced.
Level of scrutiny
Low. This is a routine Dependabot version bump following the repo's established SHA-pinning pattern. The diff is uniform and easy to verify: every touched line swaps the same old SHA for the same new SHA.
Other factors
The two findings from the bug hunter are (1) a pre-existing issue in deploy-docs.yml that predates this PR, and (2) a cosmetic nit where 8 of 9 files have the correct new SHA but retain the old # v4 comment instead of # v5.0.0. Neither affects correctness or security of the SHA-pinned workflows. The inline comments surface these for the author to address if desired.
|
|
||
| - name: Setup pnpm | ||
| uses: pnpm/action-setup@41ff72655975bd51cab0327fa583b6e92b6d3061 # v4 | ||
| uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4 |
There was a problem hiding this comment.
🟡 The SHA fc06bc1257f339d1d5d8b3a19a8cae5388b55320 corresponds to pnpm/action-setup v5.0.0, but 8 of 9 updated workflow files still carry the old # v4 comment instead of # v5.0.0. Update the comments in bundle-analysis.yml, docs-check.yml, docs-seo-aeo.yml, prepare-release.yml, release-on-tag.yml, release.yml (two instances), and stable-release.yml to read # v5.0.0.
Extended reasoning...
What the bug is
When pinning GitHub Actions by SHA, the version comment alongside the SHA is the only human-readable indicator of which version is actually in use. This PR bumps pnpm/action-setup from v4 to v5 across 9 workflow files. The SHA fc06bc1257f339d1d5d8b3a19a8cae5388b55320 is the v5.0.0 release commit.
The specific discrepancy
In ci.yml, the comment was correctly updated to # v5.0.0 alongside the new SHA. But in 8 other files, the same new SHA was used while the comment was left unchanged as # v4. Affected files: bundle-analysis.yml, docs-check.yml, docs-seo-aeo.yml, prepare-release.yml, release-on-tag.yml, release.yml (two instances), and stable-release.yml.
Why existing checks do not catch it
GitHub Actions resolves the action by SHA, not by the comment, so CI passes without error. There is no automated check that validates consistency between a pinned SHA and its version comment. The mismatch is purely a human-readable documentation issue.
Impact
Any maintainer auditing dependencies — reviewing Dependabot PRs, checking for version drift, or assessing supply-chain risk — will see # v4 and believe these jobs are still using v4, even though they are actually running v5. This defeats the entire purpose of annotating pinned SHAs with version comments: traceability and auditability are undermined.
Step-by-step proof
- The PR title is "chore(deps): bump pnpm/action-setup from 4 to 5".
- In the ci.yml diff: old SHA 41ff72655975bd51cab0327fa583b6e92b6d3061 with comment # v4.2.0 was replaced with SHA fc06bc1257f339d1d5d8b3a19a8cae5388b55320 and comment # v5.0.0. This confirms the new SHA equals v5.0.0.
- In the bundle-analysis.yml diff: old SHA 41ff72655975bd51cab0327fa583b6e92b6d3061 # v4 was replaced with fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4 — same new SHA, but comment not updated.
- A developer reading bundle-analysis.yml would conclude v4 is in use, which is incorrect.
Fix
Change the # v4 comment on all 9 affected lines across the 8 files to # v5.0.0 to match the annotation already present in ci.yml.
|
|
||
| - name: Setup pnpm | ||
| uses: pnpm/action-setup@v4 | ||
| uses: pnpm/action-setup@v5 |
There was a problem hiding this comment.
🟣 This is a pre-existing issue: deploy-docs.yml uses mutable version tags for all its actions (including pnpm/action-setup@v5 on line 27), while every other workflow in the repository pins actions to full 40-character commit SHAs. This PR changed @v4 to @v5 on this line but missed the opportunity to align it with the SHA-pinning pattern used across all other workflows. The fix would be to replace pnpm/action-setup@v5 with pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v5.0.0.
Extended reasoning...
Background
All 8 other workflow files in this repository pin GitHub Actions to full 40-character commit SHAs with a version comment (e.g. pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v5.0.0). This is a supply-chain security best practice: a pinned SHA is immutable and cannot be force-pushed, so the exact code that runs is guaranteed to match what was reviewed.
What the bug is
deploy-docs.yml diverges from this repo-wide convention. Every action reference in that file uses a mutable version tag instead of a SHA:
actions/checkout@v6pnpm/action-setup@v5(the line touched by this PR)actions/setup-node@v6cloudflare/wrangler-action@v3actions/github-script@v8
A mutable tag can be force-pushed by anyone with push access to the upstream action repo. If pnpm/action-setup or any of those action repos were compromised, an attacker could silently redirect the tag to malicious code and the workflow would execute it without any change visible in this repository.
Why this is pre-existing
This pattern predates the current PR: before this PR, deploy-docs.yml already used pnpm/action-setup@v4 (a mutable tag). The other actions in the file (checkout@v6, setup-node@v6, etc.) were also already using mutable tags. The PR did not introduce the mutable-tag pattern — it existed before.
Why the PR is the right place to flag it
The PR directly touches line 27 of deploy-docs.yml, changing @v4 to @v5. In the same commit, every other workflow was updated to use the pinned SHA fc06bc1257f339d1d5d8b3a19a8cae5388b55320. The PR author or reviewer had an explicit opportunity to apply the same pattern to deploy-docs.yml but did not.
Concrete proof
Step-by-step inconsistency:
ci.ymlline 27 (this PR):pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v5.0.0✓ pinnedrelease.ymlline 32 (this PR):pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4✓ pinneddeploy-docs.ymlline 27 (this PR):pnpm/action-setup@v5✗ mutable tag
If someone force-pushes the v5 tag on the pnpm/action-setup repo to a malicious commit, the next deploy-docs.yml run would silently execute that malicious code with write access to contents and deployments.
How to fix
Replace:
uses: pnpm/action-setup@v5with:
uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v5.0.0Ideally, the other mutable-tag references in the file (checkout@v6, setup-node@v6, wrangler-action@v3, github-script@v8) should also be pinned to SHAs in a follow-up.
Bumps pnpm/action-setup from 4 to 5.
Release notes
Sourced from pnpm/action-setup's releases.
Commits
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)