chore(deps): bump pnpm/action-setup from 5.0.0 to 6.0.0#326
chore(deps): bump pnpm/action-setup from 5.0.0 to 6.0.0#326dependabot[bot] wants to merge 1 commit intomainfrom
Conversation
Bumps [pnpm/action-setup](https://github.com/pnpm/action-setup) from 5.0.0 to 6.0.0. - [Release notes](https://github.com/pnpm/action-setup/releases) - [Commits](pnpm/action-setup@v5...v6) --- updated-dependencies: - dependency-name: pnpm/action-setup dependency-version: 6.0.0 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 SummaryRoutine Dependabot bump of Confidence Score: 5/5Safe to merge — all functional changes are correct; findings are cosmetic comment and consistency issues only. Every workflow now pins to the correct v6.0.0 commit SHA. The two P2 findings (stale # v4 comments and one mutable tag reference in deploy-docs.yml) are pre-existing style issues that do not affect runtime behavior or security in any meaningful way. deploy-docs.yml uses a tag reference instead of a SHA pin; several files carry stale # v4 version comments. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["pnpm/action-setup bump\nv5.0.0 → v6.0.0"] --> B["SHA-pinned workflows\n(8 files)"]
A --> C["Tag-pinned workflow\ndeploy-docs.yml"]
B --> D["SHA: 08c4be7e...\n✅ Correct + consistent"]
C --> E["@v6.0.0 tag\n⚠️ Mutable reference"]
B --> F["Version comments\n⚠️ 7 files still say '# v4'"]
D --> G["ci.yml ✅\nbundle-analysis.yml\ndocs-check.yml\ndocs-seo-aeo.yml\nprepare-release.yml\nrelease-on-tag.yml\nrelease.yml x2\nstable-release.yml"]
Prompt To Fix All With AIThis is a comment left during a code review.
Path: .github/workflows/deploy-docs.yml
Line: 26
Comment:
**No SHA pin on `deploy-docs.yml`**
This workflow uses a mutable tag reference (`@v6.0.0`) while all other workflows in this PR use a full commit SHA. If the tag is ever force-pushed, this workflow would silently run a different version. Consider pinning to the same SHA used elsewhere (`08c4be7e2e672a47d11bd04269e27e5f3e8529cb`).
```suggestion
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
```
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: .github/workflows/bundle-analysis.yml
Line: 31
Comment:
**Stale version comment after bump**
The SHA now points to v6.0.0 but the inline comment still reads `# v4`. The same pattern appears in `docs-check.yml`, `docs-seo-aeo.yml`, `prepare-release.yml`, `release-on-tag.yml`, `release.yml` (both jobs), and `stable-release.yml`. Only `ci.yml` was updated correctly. Consider updating the comments to `# v6.0.0` across all affected files for consistency with `ci.yml`.
```suggestion
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
```
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}
| @@ -24,7 +24,7 @@ jobs: | |||
| uses: actions/checkout@v6 | |||
|
|
|||
| - name: Setup pnpm | |||
There was a problem hiding this comment.
deploy-docs.yml
This workflow uses a mutable tag reference (@v6.0.0) while all other workflows in this PR use a full commit SHA. If the tag is ever force-pushed, this workflow would silently run a different version. Consider pinning to the same SHA used elsewhere (08c4be7e2e672a47d11bd04269e27e5f3e8529cb).
| - name: Setup pnpm | |
| uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0 |
Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/workflows/deploy-docs.yml
Line: 26
Comment:
**No SHA pin on `deploy-docs.yml`**
This workflow uses a mutable tag reference (`@v6.0.0`) while all other workflows in this PR use a full commit SHA. If the tag is ever force-pushed, this workflow would silently run a different version. Consider pinning to the same SHA used elsewhere (`08c4be7e2e672a47d11bd04269e27e5f3e8529cb`).
```suggestion
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
```
How can I resolve this? If you propose a fix, please make it concise.|
|
||
| - name: Setup pnpm | ||
| uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4 | ||
| uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v4 |
There was a problem hiding this comment.
The SHA now points to v6.0.0 but the inline comment still reads # v4. The same pattern appears in docs-check.yml, docs-seo-aeo.yml, prepare-release.yml, release-on-tag.yml, release.yml (both jobs), and stable-release.yml. Only ci.yml was updated correctly. Consider updating the comments to # v6.0.0 across all affected files for consistency with ci.yml.
| uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v4 | |
| uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0 |
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 comment after bump**
The SHA now points to v6.0.0 but the inline comment still reads `# v4`. The same pattern appears in `docs-check.yml`, `docs-seo-aeo.yml`, `prepare-release.yml`, `release-on-tag.yml`, `release.yml` (both jobs), and `stable-release.yml`. Only `ci.yml` was updated correctly. Consider updating the comments to `# v6.0.0` across all affected files for consistency with `ci.yml`.
```suggestion
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
```
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}
|
|
||
| - name: Setup pnpm | ||
| uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v4 | ||
| uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v4 |
There was a problem hiding this comment.
🟡 Eight workflow files have their pnpm/action-setup hash updated to the v6.0.0 release commit (08c4be7e), but the inline version comments still read # v4 instead of # v6.0.0. The comments should be updated to # v6.0.0 in: bundle-analysis.yml, docs-check.yml, docs-seo-aeo.yml, prepare-release.yml, release-on-tag.yml, release.yml (2 places), and stable-release.yml.
Extended reasoning...
What the bug is and how it manifests
This PR bumps pnpm/action-setup from v5.0.0 to v6.0.0 by updating the pinned commit hash to 08c4be7e2e672a47d11bd04269e27e5f3e8529cb. The convention in this repo is to pin actions by full commit SHA for security, with an inline comment documenting the human-readable version tag (e.g., # v6.0.0). The PR correctly updated the hash in all 9 workflow files, but only updated the version comment in one of them (ci.yml). The remaining 8 files now have a mismatch between the actual version being executed (v6.0.0) and what the comment says (v4).
The specific code path that triggers it
In ci.yml, the line was changed from:
uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v5.0.0
to:
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0
But in bundle-analysis.yml, docs-check.yml, docs-seo-aeo.yml, prepare-release.yml, release-on-tag.yml, release.yml (lines 32 and 136), and stable-release.yml, the same hash change was applied while retaining # v4 — which was already stale before this PR (those files were using the v5 hash fc06bc12 but commenting it as # v4).
Why existing code doesn't prevent it
There is no automated check that validates the consistency between the pinned commit hash and the version comment. The discrepancy is a purely human/tooling oversight — Dependabot updated the hashes but did not update the comments in the affected files.
What the impact would be
The workflows will function correctly because GitHub Actions resolves the commit SHA, not the comment. However, the comments exist specifically to aid human auditing: when a developer reviews these files to verify which version of a third-party action is being used, they will see # v4 and believe the workflow is running v4.x, when it is actually running v6.0.0. This is misleading for security audits and dependency tracking.
How to fix it
Update all 8 affected files, changing # v4 to # v6.0.0 on the pnpm/action-setup line. For example, in bundle-analysis.yml line 31:
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0Step-by-step proof
- The PR title states this bumps pnpm/action-setup from 5.0.0 to 6.0.0.
- The PR description lists commit
08c4be7as the v6.0.0 release commit. - In the diff for
ci.yml: old hashfc06bc12... # v5.0.0→ new hash08c4be7e... # v6.0.0✓ (correct). - In the diff for
bundle-analysis.yml: old hashfc06bc12... # v4→ new hash08c4be7e... # v4✗ (comment not updated). - Steps 4 repeats for docs-check.yml, docs-seo-aeo.yml, prepare-release.yml, release-on-tag.yml, release.yml (twice), and stable-release.yml.
- A developer reading bundle-analysis.yml would see
# v4and incorrectly conclude the workflow uses pnpm/action-setup v4, when it actually uses v6.0.0.
| - name: Setup pnpm | ||
| uses: pnpm/action-setup@v5 | ||
| uses: pnpm/action-setup@v6.0.0 | ||
|
|
There was a problem hiding this comment.
🟣 deploy-docs.yml uses pnpm/action-setup@v6.0.0 (a mutable tag) while all 8 other workflows updated in this PR use the pinned commit SHA 08c4be7e2e672a47d11bd04269e27e5f3e8529cb. This is a pre-existing issue — deploy-docs.yml was already using mutable tags for all its actions (checkout@v6, setup-node@v6, wrangler-action@v3, github-script@v8) before this PR — but since this PR touched this exact line, it was an opportunity to bring it in line with the pinned-hash approach used everywhere else. Consider updating to: uses: pnpm/action-setup@08c4be7 # v6.0.0
Extended reasoning...
What the bug is: deploy-docs.yml line 28 uses pnpm/action-setup@v6.0.0 — a mutable semver tag — while all 8 other workflow files updated in this same PR use the pinned commit hash 08c4be7e2e672a47d11bd04269e27e5f3e8529cb. A mutable tag means the tag can be force-pushed to point to different commit content at any time, so the action that actually runs can silently change without the workflow file changing.
The specific code path: In deploy-docs.yml, the "Setup pnpm" step resolves pnpm/action-setup@v6.0.0 at runtime. GitHub Actions resolves this to whatever commit the v6.0.0 tag points to at execution time. If the tag is moved (e.g., in response to a supply chain compromise), all future runs of this workflow will execute attacker-controlled code with the workflow's permissions (contents: read, deployments: write, pull-requests: write).
Why existing code doesn't prevent it: The other 8 workflows were correctly updated to use the immutable SHA 08c4be7e2e672a47d11bd04269e27e5f3e8529cb, which resolves to exactly one specific git object and can never be silently changed. deploy-docs.yml was not given the same treatment — it was only bumped from @v5 to @v6.0.0, both being mutable references. Furthermore, deploy-docs.yml uses mutable tags for all its other actions as well: checkout@v6, setup-node@v6, cloudflare/wrangler-action@v3, and github-script@v8.
Pre-existing nature: This is a pre-existing issue. The entire deploy-docs.yml file used mutable tags before this PR. The PR updated pnpm/action-setup from @v5 to @v6.0.0 but did not fix the underlying security posture, whereas the other 8 files were properly pinned.
Impact: The deploy-docs workflow has write access to deployments and pull-requests, making it a higher-value target. A compromised mutable action tag could exfiltrate secrets (CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID), post malicious PR comments, or manipulate Cloudflare Pages deployments.
How to fix: Replace the mutable tag with the pinned hash that is already used across all other workflows:
- name: Setup pnpm
uses: pnpm/action-setup@08c4be7e2e672a47d11bd04269e27e5f3e8529cb # v6.0.0Ideally, all other mutable action references in this file (checkout@v6, setup-node@v6, wrangler-action@v3, github-script@v8) should also be pinned to their respective commit SHAs.
Step-by-step proof:
- This PR updates deploy-docs.yml line 28 from pnpm/action-setup@v5 to pnpm/action-setup@v6.0.0
- The diff for ci.yml shows the correct pattern: pnpm/action-setup@08c4be7 # v6.0.0
- Same pinned SHA appears in bundle-analysis.yml, docs-check.yml, docs-seo-aeo.yml, prepare-release.yml, release-on-tag.yml, release.yml (×2), and stable-release.yml — 9 total pinned occurrences vs. 1 mutable reference remaining in deploy-docs.yml
- If an attacker forces the pnpm/action-setup v6.0.0 tag to point to malicious code, every subsequent deploy-docs.yml run would execute that code — while all 8 other workflows remain unaffected due to immutable SHA pinning
Bumps pnpm/action-setup from 5.0.0 to 6.0.0.
Release notes
Sourced from pnpm/action-setup's releases.
Commits
08c4be7docs(README): update action-setup version5798914chore: update .gitignoreddffd66fix: remove accidentally committed fileb43f991fix: update pnpm to 11.0.0-rc.03852509README.md: bring versions up-to-date (#222)6e7bdbdchore: bump bootstrap pnpm to 11.0.0-beta.4-1 and add update script6b87c46fix: Windows standalone mode — bypass broken npm shims (#217)994d756feat: read pnpm version from devEngines.packageManager (#211)738f428docs: upgrade pnpm/action-setup from v4 to v562bce64fix: extract pnpm version from packageManager field instead of returning unde...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)