chore: use pull_request_target for auto-labeler on fork PRs - #488
Conversation
When a PR is opened from a fork repository, the GITHUB_TOKEN in pull_request events only has read permissions, preventing the autolabeler from adding labels. Using pull_request_target runs the workflow in the context of the base repository with write permissions, which is safe since the autolabeler only reads PR metadata and adds labels without checking out any code. Fixes auto-labeler failing on PR #487 from a fork.
✅ Deploy Preview for commit-check ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
📝 WalkthroughWalkthroughThe pull request labeler workflow trigger changes from ChangesLabeler workflow
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
|
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/labeler.yml:
- Around line 4-5: Pin the privileged reusable workflow referenced by the
pull_request_target workflow to an audited, full-length immutable commit SHA
instead of the mutable main branch. Update the pr-labeler.yml invocation while
preserving the existing pull-requests write permission, and ensure the workflow
does not check out or execute code from the forked pull request.
🪄 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 Plus
Run ID: 6c5543a2-46cd-4ff4-aa5f-70735bd17d28
📒 Files selected for processing (1)
.github/workflows/labeler.yml
| # pull_request_target event is required for auto-labeler on fork PRs | ||
| pull_request_target: |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow file =="
cat -n .github/workflows/labeler.yml
echo
echo "== referenced reusable workflow metadata/contents if present =="
if [ -f .github/commit-check/.github/.github/workflows/pr-labeler.yml ]; then
wc -l .github/commit-check/.github/.github/workflows/pr-labeler.yml
cat -n .github/commit-check/.github/.github/workflows/pr-labeler.yml
else
echo "referenced file not present in tree"
fi
echo
echo "== search for pr-labeler workflow usage/checkouts =="
rg -n "pr-labeler\.yml|pull_request_target|pull-requests: write|actions/checkout|checkout|\${{\s*github\.event\.pull_request|github\.event\.pull_request" .github -S || trueRepository: commit-check/commit-check
Length of output: 1105
🌐 Web query:
commit-check .github workflows pr-labeler.yml main
💡 Result:
The term "commit-check" in a GitHub Actions workflow typically refers to the use of the Commit Check tool [1][2], a policy engine used to validate Git commit metadata such as commit messages, branch names, and author information [1][3][4]. While users may name their workflow files anything (e.g., pr-labeler.yml) [5], the specific action provided by the Commit Check project is commonly implemented in a dedicated workflow file like.github/workflows/commit-check.yml [3][6]. To integrate Commit Check into your workflow, you can add the following step to your GitHub Actions file [3][4]: - uses: commit-check/commit-check-action@v2 with: message: true branch: true # Optional configurations author-name: false author-email: false job-summary: true pr-comments: ${{ github.event_name == 'pull_request' }} Key requirements for this action include: 1. Using actions/checkout@v5 with fetch-depth: 0 to ensure the full history is available for validation [3][4][6]. 2. Optionally providing a cchk.toml file in your repository root to customize policies [2][6]. If you are encountering a workflow named pr-labeler.yml that includes a commit check, it is likely a custom implementation where the developer has combined automated PR labeling with a commit validation step (often using actions/github-script or custom bash scripts) to enforce project standards [7][8][9]. Unlike the dedicated Commit Check action, these custom implementations often use regex patterns or API calls to validate commit titles directly within the PR workflow [7][8].
Citations:
- 1: https://commit-check.github.io/commit-check/
- 2: https://pypi.org/project/commit-check/
- 3: https://github.com/commit-check/commit-check-action
- 4: https://commit-check.github.io/
- 5: https://github.com/ruzickap/my-git-projects/actions/workflows/pr-size-labeler.yml
- 6: https://github.com/marketplace/actions/commit-check-action
- 7: https://github.com/alexneamtu/htoprc.dev/blob/6163fe03a5a44d50b3443bf77d03764bd6a30be2/.github/workflows/pr-checks.yml
- 8: https://github.com/leplusorg/docker-md/blob/acfdf7c8ebfa992e0605f588306a570a72120094/.github/workflows/check-pr.yml
- 9: https://github.com/troylar/devsync/blob/ba0ca2671feac736571242302876a0f4317671c2/.github/workflows/pr-automation.yml
🌐 Web query:
site:github.com/commit-check/.github .github/workflows/pr-labeler.yml
💡 Result:
The file path.github/workflows/pr-labeler.yml is a common convention for a GitHub Actions workflow file designed to automatically label pull requests. While the specific file name is user-defined, it typically leverages the official actions/labeler GitHub Action to categorize pull requests based on the files they modify. To implement this functionality, you generally need two components: 1. A workflow file (e.g.,.github/workflows/pr-labeler.yml) that triggers on pull request events. 2. A configuration file (often located at.github/labeler.yml) that defines the rules for which files should trigger which labels. Example configuration for.github/workflows/pr-labeler.yml: name: Pull Request Labeler on: pull_request_target: types: [opened, synchronize, reopened] jobs: label: runs-on: ubuntu-latest permissions: contents: read pull-requests: write steps: - uses: actions/labeler@v5 with: repo-token: ${{ secrets.GITHUB_TOKEN }} The corresponding.github/labeler.yml file would map patterns to labels, such as: documentation: - docs/ - README.md frontend: - src/ui/ The provided search results did not contain specific implementation details for this file path within the referenced repositories.
Citations:
- 1: https://github.com/commit-check/.github
- 2: https://github.com/commit-check/.github/blob/main/CONTRIBUTING.md
- 3: https://github.com/commit-check/.github/blob/main/SECURITY.md
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== git diff stat and any workflow-related diff context =="
git diff --stat || true
git diff -- .github/workflows/labeler.yml .github/commit-check/.github/.github/workflows/pr-labeler.yml || true
echo
echo "== workflow references to pull_request_target/reusable workflow/permissions =="
rg -n "pull_request_target|pull-requests:\s*write|uses:\s*commit-check/.github/.github/workflows/pr-labeler.yml|actions/github-script|actions/checkout|\$\{\{\s*github\.event\.github\.event_name|github\.event\." .github/workflows/labeler.yml .github/commit-check/.github/.github/workflows/pr-labeler.yml 2>/dev/null || trueRepository: commit-check/commit-check
Length of output: 621
Pin the privileged reusable workflow to an immutable commit SHA.
pull_request_target grants pull-requests: write to the reusable workflow at @main, so that mutable branch can receive write access if changed. Pin pr-labeler.yml to an audited full-length commit SHA and ensure it does not check out or execute fork code.
🤖 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/labeler.yml around lines 4 - 5, Pin the privileged
reusable workflow referenced by the pull_request_target workflow to an audited,
full-length immutable commit SHA instead of the mutable main branch. Update the
pr-labeler.yml invocation while preserving the existing pull-requests write
permission, and ensure the workflow does not check out or execute code from the
forked pull request.



Summary
When a PR is opened from a fork repository (e.g. #487 by @XEDAB), the
pull_requestevent'sGITHUB_TOKENhas read-only permissions, causing the autolabeler to fail with:Changing to
pull_request_targetruns the workflow in the context of the base repository, giving the token write permissions needed to add labels.Why this is safe
The autolabeler (
release-drafter/release-drafter/autolabeler) only:It does not checkout any code from the fork, so there is no security risk from using
pull_request_target.Related
Summary by CodeRabbit