Build: Let DangerJS run with our script and token on forks#34013
Build: Let DangerJS run with our script and token on forks#34013
Conversation
|
View your CI Pipeline Execution ↗ for commit 2585708
☁️ Nx Cloud last updated this comment at |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe GitHub Actions workflow Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/danger-js.yml:
- Line 2: Change the workflow that uses the pull_request_target event to
explicitly scope GITHUB_TOKEN and avoid persisting checkout credentials: add a
top-level permissions block (e.g., permissions: contents: read, pull-requests:
write) to grant least-privilege access instead of default read/write, and in any
job that uses actions/checkout set with: persist-credentials: false so checkout
does not expose the token; look for the pull_request_target event and update the
workflow to include the permissions block and the actions/checkout
persist-credentials change.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6f22c7c1-ae9b-47a2-b198-75109aef0542
📒 Files selected for processing (1)
.github/workflows/danger-js.yml
| @@ -1,5 +1,5 @@ | |||
| on: | |||
| pull_request: | |||
| pull_request_target: | |||
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions pull_request_target default GITHUB_TOKEN permissions
💡 Result:
For workflows triggered by pull_request_target, the GITHUB_TOKEN is granted read/write repository permissions by default, even if the pull request comes from a fork. [1]
However, the effective default permissions still start from your repo/org/enterprise “Workflow permissions” setting (restricted vs read/write), and can be further reduced/overridden by permissions: in the workflow (workflow- or job-level). Also, org/enterprise policies can enforce a more restrictive default. [1], [2], [3]
Key default-setting note: GitHub’s default “Workflow permissions” depends on when the org/enterprise was created (newer orgs default to read-only; older may default to read/write), but pull_request_target is the special case that runs in the base-repo context and thus can receive elevated permissions unless you explicitly restrict them. [1], [2]
Sources:
[1] GitHub Docs – Workflow syntax / how GITHUB_TOKEN permissions are calculated + pull_request_target read/write note
[2] GitHub Docs – Enterprise policy: default GITHUB_TOKEN permissions depend on org/enterprise creation date
[3] GitHub Docs – Repository Actions settings: configuring default GITHUB_TOKEN permissions
🌐 Web query:
Danger JS GitHub Actions required permissions comments pull requests
💡 Result:
To let Danger JS post a comment/status/check on a pull request from GitHub Actions using GITHUB_TOKEN, your workflow job must grant write scopes explicitly (especially if your repo/org defaults GITHUB_TOKEN to read-only).
Minimal required job permissions (common for Danger commenting + reporting)
permissions:
pull-requests: write
checks: write
statuses: writeThese are the permissions required by a commonly used Danger JS GitHub Action implementation. [1]
Token note (fork PRs / Dependabot)
On workflows triggered by pull_request from forks (and commonly Dependabot), GITHUB_TOKEN is read-only, so Danger can’t comment via the API. [2] Options people use:
- Use a separate token (PAT / GitHub App) with PR write access (stored as a secret), or
- Use
pull_request_targetto get base-repo permissions but treat it as high-risk and avoid checking out/executing untrusted PR code. [3]
Why you may need to set permissions: even if it “used to work”
GitHub lets orgs/enterprises default GITHUB_TOKEN to read-only; workflows then must opt-in per job using permissions:. [4]
Sources: [1] [2] [3] [4]
Scope GITHUB_TOKEN permissions explicitly after moving to pull_request_target.
Line 2 changes the workflow to a higher-trust event context where the token receives read/write repository permissions by default, even for fork pull requests. Add an explicit permissions block with least-privilege scopes and avoid persisting checkout credentials by default.
Suggested hardening patch
on:
pull_request_target:
name: Danger JS
+permissions:
+ contents: read
+ pull-requests: write
+ checks: write
+ statuses: write
jobs:
dangerJS:
steps:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@v4
+ with:
+ persist-credentials: false
- name: Danger JS
uses: docker://ghcr.io/danger/danger-js:13.0.5🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/danger-js.yml at line 2, Change the workflow that uses the
pull_request_target event to explicitly scope GITHUB_TOKEN and avoid persisting
checkout credentials: add a top-level permissions block (e.g., permissions:
contents: read, pull-requests: write) to grant least-privilege access instead of
default read/write, and in any job that uses actions/checkout set with:
persist-credentials: false so checkout does not expose the token; look for the
pull_request_target event and update the workflow to include the permissions
block and the actions/checkout persist-credentials change.
There was a problem hiding this comment.
Not dangerous because of how little we do in dangerjs but ideally we should use a separate token that can only do what dangerjs needs
3 participants
What I did
Third-party repos can't run DangerJS any more. So our external contributors don't receive the feedback we designed DangerJS to provide them with.
See logs: https://github.com/storybookjs/storybook/actions/workflows/danger-js.yml?query=is%3Afailure
This PR switches the DangerJS workflow from running the source branch's code with the source secrets (aka, the fork) to running the target branch with its secret (aka the script on
next, with our GitHub token).Checklist for Contributors
Testing
The changes in this PR are covered in the following automated tests:
ø
Manual testing
Will try to run a PR against this one, hopefully it should trigger with the right permissions.
Documentation
ø
Checklist for Maintainers
When this PR is ready for testing, make sure to add
ci:normal,ci:mergedorci:dailyGH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/lib/cli-storybook/src/sandbox-templates.tsMake sure this PR contains one of the labels below:
Available labels
bug: Internal changes that fixes incorrect behavior.maintenance: User-facing maintenance tasks.dependencies: Upgrading (sometimes downgrading) dependencies.build: Internal-facing build tooling & test updates. Will not show up in release changelog.cleanup: Minor cleanup style change. Will not show up in release changelog.documentation: Documentation only changes. Will not show up in release changelog.feature request: Introducing a new feature.BREAKING CHANGE: Changes that break compatibility in some way with current major version.other: Changes that don't fit in the above categories.🦋 Canary release
This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the
@storybookjs/coreteam here.core team members can create a canary release here or locally with
gh workflow run --repo storybookjs/storybook publish.yml --field pr=<PR_NUMBER>Summary by CodeRabbit