test suzuki-shunsuke/tibdex-github-app-token#379
Conversation
📝 WalkthroughWalkthroughThe test workflow is refactored to authenticate PR comments via GitHub App tokens instead of a custom action. The trigger is simplified to all pull requests, conditional gating is removed, and the notification step is replaced with app token generation followed by native ChangesWorkflow Authentication Refactor
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
hello |
![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 current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/test.yaml:
- Around line 3-14: The workflow currently triggers on pull_request which
disallows access to secrets for forked PRs; change the trigger to
pull_request_target (or split the token-creation into a separate job triggered
by pull_request_target) so the create_token step (uses:
suzuki-shunsuke/tibdex-github-app-token) can access secrets.APP_PRIVATE_KEY; if
you use pull_request_target ensure you still checkout the PR head (use the
appropriate checkout ref for github.event.pull_request.head.sha) before running
actions that use repository code so the rest of the job (including the
subsequent gh pr comment step) operates against the PR changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 389aa1c3-d17e-4d7d-b779-d43d4d90f041
📒 Files selected for processing (1)
.github/workflows/test.yaml
| on: pull_request | ||
| jobs: | ||
| test: | ||
| if: | | ||
| endsWith(github.event.pull_request.user.login, '[bot]') && | ||
| ((github.event_name == 'pull_request_review' && github.event.review.state == 'approved') || | ||
| github.event_name == 'pull_request') | ||
| runs-on: ubuntu-24.04 | ||
| timeout-minutes: 15 | ||
| permissions: | ||
| pull-requests: write | ||
| contents: read | ||
| permissions: {} | ||
| steps: | ||
| - uses: suzuki-shunsuke/notify-bot-pr-event-action@pr/1 | ||
| - id: create_token | ||
| uses: suzuki-shunsuke/tibdex-github-app-token@55429bbc082600559820fc71ef237b3f0e2a50a1 # v3.0.0 | ||
| with: | ||
| app_id: ${{ vars.APP_ID }} | ||
| private_key: ${{ secrets.APP_PRIVATE_KEY }} |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For GitHub Actions, are repository secrets available to workflows triggered by pull_requestfrom forks, and when ispull_request_target the correct alternative?
💡 Result:
Yes—when a workflow is triggered by pull_request from a fork, GitHub does not pass repository secrets to the runner (with the exception of GITHUB_TOKEN). [1][2] When to use pull_request_target: use it when you need access to the base repository’s secrets (or otherwise need the privileged context of the target repository) while responding to a pull request. GitHub introduced pull_request_target specifically to give the workflow access to secrets/read-write GITHUB_TOKEN so maintainers can safely perform tasks like commenting/labeling on PRs. [3] However, pull_request_target is dangerous if your workflow checks out and runs untrusted code from the pull request; GitHub’s Security Lab warns that combining it with an explicit checkout/build/run of untrusted PR code can lead to repository compromise, because the workflow runs in the context of the base repo with secrets available. [4] Rule of thumb: - If you only need to test untrusted code: prefer pull_request (secrets withheld by design). [4][2] - If you truly need base repo secrets: use pull_request_target, but do not blindly execute the PR’s code—only use it for trusted tasks, and/or gate execution carefully (e.g., separate trusted workflow steps, approvals, and strict handling of what is checked out/executed). [4] Related note: for fork PRs using pull_request_target, GitHub documents that GITHUB_TOKEN is granted read/write repository permission even when triggered from a public fork. [5]
Citations:
- 1: https://stackoverflow.com/questions/76746551/how-to-use-github-actions-environment-secrets-in-open-source-pull-request-ci-wor
- 2: https://docs.github.com/en/actions/concepts/security/compromised-runners
- 3: https://github.blog/news-insights/product-news/github-actions-improvements-for-fork-and-pull-request-workflows
- 4: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests
- 5: https://docs.github.com/actions/reference/workflow-syntax-for-github-actions
🏁 Script executed:
cat -n .github/workflows/test.yamlRepository: szksh-lab-2/test-github-action
Length of output: 797
pull_request prevents app-secret usage on fork PRs.
Line 3 + Line 14 are incompatible for forked PR validation: secrets.APP_PRIVATE_KEY is not available on fork-triggered pull_request runs, so token creation fails and the gh pr comment step cannot execute.
Suggested fix
-on: pull_request
+on:
+ pull_request_target:
+ types: [opened, reopened, synchronize]📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| on: pull_request | |
| jobs: | |
| test: | |
| if: | | |
| endsWith(github.event.pull_request.user.login, '[bot]') && | |
| ((github.event_name == 'pull_request_review' && github.event.review.state == 'approved') || | |
| github.event_name == 'pull_request') | |
| runs-on: ubuntu-24.04 | |
| timeout-minutes: 15 | |
| permissions: | |
| pull-requests: write | |
| contents: read | |
| permissions: {} | |
| steps: | |
| - uses: suzuki-shunsuke/notify-bot-pr-event-action@pr/1 | |
| - id: create_token | |
| uses: suzuki-shunsuke/tibdex-github-app-token@55429bbc082600559820fc71ef237b3f0e2a50a1 # v3.0.0 | |
| with: | |
| app_id: ${{ vars.APP_ID }} | |
| private_key: ${{ secrets.APP_PRIVATE_KEY }} | |
| on: | |
| pull_request_target: | |
| types: [opened, reopened, synchronize] | |
| jobs: | |
| test: | |
| runs-on: ubuntu-24.04 | |
| timeout-minutes: 15 | |
| permissions: {} | |
| steps: | |
| - id: create_token | |
| uses: suzuki-shunsuke/tibdex-github-app-token@55429bbc082600559820fc71ef237b3f0e2a50a1 # v3.0.0 | |
| with: | |
| app_id: ${{ vars.APP_ID }} | |
| private_key: ${{ secrets.APP_PRIVATE_KEY }} |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/test.yaml around lines 3 - 14, The workflow currently
triggers on pull_request which disallows access to secrets for forked PRs;
change the trigger to pull_request_target (or split the token-creation into a
separate job triggered by pull_request_target) so the create_token step (uses:
suzuki-shunsuke/tibdex-github-app-token) can access secrets.APP_PRIVATE_KEY; if
you use pull_request_target ensure you still checkout the PR head (use the
appropriate checkout ref for github.event.pull_request.head.sha) before running
actions that use repository code so the rest of the job (including the
subsequent gh pr comment step) operates against the PR changes.
1 participant
Summary by CodeRabbit