Add contributor templates, issue forms, and PR triage automation#58
Add contributor templates, issue forms, and PR triage automation#58beardthelion wants to merge 7 commits into
Conversation
📝 WalkthroughWalkthroughAdds GitHub contributor infrastructure: a CODEOWNERS file, three issue form templates (bug report, feature request, template config), a PR description template, a PR triage workflow that reconciles labels and posts guidance comments based on PR content signals, a stale-PR workflow, and a CONTRIBUTING.md section documenting triage bot behavior. ChangesGitHub Contributor Infrastructure
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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/pr-triage.yml:
- Around line 72-74: The touchedTests variable currently satisfies test coverage
when any file path includes "/tests/" regardless of file type, which incorrectly
clears the needs-tests label when non-Rust tests are touched but Rust source
changed. Modify the condition in the names.some() check to scope the "/tests/"
path detection to Rust files only by requiring files in "/tests/" directories to
also end with the ".rs" extension, ensuring only Rust test files satisfy the
test coverage requirement.
- Around line 3-5: The workflow currently uses the `pull_request` event trigger
which restricts GITHUB_TOKEN to read-only permissions for forked PRs, causing
write operations (labels and comments) to fail with a 403 error. Change the
trigger from `pull_request` to `pull_request_target` in the `on:` section to run
in the base repository context with write permissions. When making this change,
ensure that any steps writing labels or comments do not check out or execute
untrusted code from the PR branch; instead, use the `github.event` context data
directly to safely access PR information while preserving write access.
In @.github/workflows/stale.yml:
- Line 27: The `only-pr-labels` configuration requires PRs to have all specified
labels simultaneously, but the intended behavior is to mark PRs stale if they
contain any of the specified labels. Replace the `only-pr-labels` key with
`any-of-pr-labels` in the stale workflow configuration to ensure PRs that have
either "needs-issue" or "needs-description" labels are processed according to
the triage policy.
🪄 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: 4c5555f0-f178-47fc-98a4-2c44fa7e089a
📒 Files selected for processing (8)
.github/CODEOWNERS.github/ISSUE_TEMPLATE/bug_report.yml.github/ISSUE_TEMPLATE/config.yml.github/ISSUE_TEMPLATE/feature_request.yml.github/pull_request_template.md.github/workflows/pr-triage.yml.github/workflows/stale.ymlCONTRIBUTING.md
| on: | ||
| pull_request: | ||
| types: [opened, edited, synchronize, reopened] |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For GitHub Actions as of 2026: when a workflow is triggered by pull_requestfrom a fork, canGITHUB_TOKENwithissues: write/pull-requests: write actually add labels and post PR comments, or is it still read-only?
💡 Result:
As of 2026, when a workflow is triggered by the pull_request event from a forked repository, the GITHUB_TOKEN is automatically restricted to read-only permissions, regardless of any permissions configuration defined in your workflow [1][2][3]. This is a security feature designed to prevent unauthorized code in a fork from accessing secrets or performing write operations in the target repository [4][5]. Consequently, attempts to add labels or post PR comments using this token will fail with a "Resource not accessible by integration" (403) error [1][6][7]. To perform these actions for pull requests from forks, you must use the pull_request_target event instead of pull_request [1][6][5]. The pull_request_target event triggers the workflow in the context of the base repository (the target branch) rather than the fork's branch, which allows the GITHUB_TOKEN to retain the write permissions granted in your workflow's permissions block [1][7][5]. When using pull_request_target, it is critical to observe security best practices, as the workflow has access to the target repository's secrets and write permissions [1][4]. Specifically: 1. Never check out or execute code directly from the forked PR branch if you use pull_request_target, as this could allow malicious code to access your repository's tokens and secrets [1][7]. 2. If you need to process PR data (like the title, body, or issue number), use the data available in the github.event context rather than checking out the untrusted code [7]. 3. Ensure your workflow only performs the intended automation (such as applying labels or posting a standard comment) and does not inadvertently expose the token to untrusted user input [7].
Citations:
- 1: https://devopsil.com/articles/2026-03-30-github-actions-resource-not-accessible-fix
- 2: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
- 3: https://github.com/10up/action-repo-automator
- 4: https://netomi.github.io/eclipse/2024/08/21/adding-comments-to-pr.html
- 5: https://jacobtomlinson.dev/posts/2022/commenting-on-pull-requests-with-github-actions/
- 6: Labels not applied on PRs FROM forks actions/labeler#399
- 7: https://github.com/pasrom/meeting-transcriber/blob/2e9b8718ba97944044657f0d02976de6d0f691e2/.github/workflows/pr-labels.yml
🏁 Script executed:
cat -n .github/workflows/pr-triage.yml | sed -n '1,10p'Repository: Gitlawb/node
Length of output: 284
🏁 Script executed:
wc -l .github/workflows/pr-triage.ymlRepository: Gitlawb/node
Length of output: 92
🏁 Script executed:
cat -n .github/workflows/pr-triage.yml | sed -n '3,5p'Repository: Gitlawb/node
Length of output: 148
🏁 Script executed:
cat -n .github/workflows/pr-triage.yml | sed -n '80,130p'Repository: Gitlawb/node
Length of output: 2522
Switch to pull_request_target event to enable fork PR write operations.
The current pull_request trigger automatically restricts GITHUB_TOKEN to read-only for forked PRs, causing the label and comment writes at lines 85, 88, and 120 to fail with a 403 error. Use pull_request_target instead, which runs in the base repository context and preserves write permissions. Note: when using pull_request_target, avoid checking out or executing untrusted code from the PR branch; use github.event context data instead.
🤖 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/pr-triage.yml around lines 3 - 5, The workflow currently
uses the `pull_request` event trigger which restricts GITHUB_TOKEN to read-only
permissions for forked PRs, causing write operations (labels and comments) to
fail with a 403 error. Change the trigger from `pull_request` to
`pull_request_target` in the `on:` section to run in the base repository context
with write permissions. When making this change, ensure that any steps writing
labels or comments do not check out or execute untrusted code from the PR
branch; instead, use the `github.event` context data directly to safely access
PR information while preserving write access.
Source: MCP tools
| const touchedTests = | ||
| names.some(n => n.includes("/tests/") || n.endsWith("_test.rs")) || addsInlineTest; | ||
| if (changedRust && !touchedTests) want.add("needs-tests"); |
There was a problem hiding this comment.
Scope the test signal to Rust test paths only.
Line 72 currently treats any "/tests/" path as satisfying Rust test coverage. That can clear needs-tests even when Rust source changed but only non-Rust tests were touched.
Suggested fix
- const touchedTests =
- names.some(n => n.includes("/tests/") || n.endsWith("_test.rs")) || addsInlineTest;
- if (changedRust && !touchedTests) want.add("needs-tests");
+ const touchedRustTests =
+ names.some(n =>
+ n.startsWith("crates/") &&
+ n.endsWith(".rs") &&
+ (n.includes("/tests/") || n.endsWith("_test.rs") || n.endsWith("_tests.rs"))
+ ) || addsInlineTest;
+ if (changedRust && !touchedRustTests) want.add("needs-tests");🤖 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/pr-triage.yml around lines 72 - 74, The touchedTests
variable currently satisfies test coverage when any file path includes "/tests/"
regardless of file type, which incorrectly clears the needs-tests label when
non-Rust tests are touched but Rust source changed. Modify the condition in the
names.some() check to scope the "/tests/" path detection to Rust files only by
requiring files in "/tests/" directories to also end with the ".rs" extension,
ensuring only Rust test files satisfy the test coverage requirement.
| days-before-issue-stale: -1 | ||
| days-before-issue-close: -1 | ||
| # Only PRs the triage step flagged as needing an author response. | ||
| only-pr-labels: "needs-issue,needs-description" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify actions/stale input semantics directly from upstream action metadata/docs.
set -euo pipefail
curl -fsSL https://raw.githubusercontent.com/actions/stale/main/README.md | rg -n "only-pr-labels|any-of-pr-labels|contain all|contain one"Repository: Gitlawb/node
Length of output: 2219
Change only-pr-labels to any-of-pr-labels to match intended triage behavior.
The only-pr-labels filter requires PRs to have all specified labels. This means PRs with only needs-issue or only needs-description will not be marked stale, conflicting with the intended policy. Use any-of-pr-labels to process PRs that contain any one of these labels.
Suggested fix
- only-pr-labels: "needs-issue,needs-description"
+ any-of-pr-labels: "needs-issue,needs-description"📝 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.
| only-pr-labels: "needs-issue,needs-description" | |
| any-of-pr-labels: "needs-issue,needs-description" |
🤖 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/stale.yml at line 27, The `only-pr-labels` configuration
requires PRs to have all specified labels simultaneously, but the intended
behavior is to mark PRs stale if they contain any of the specified labels.
Replace the `only-pr-labels` key with `any-of-pr-labels` in the stale workflow
configuration to ensure PRs that have either "needs-issue" or
"needs-description" labels are processed according to the triage policy.
Source: MCP tools
1 participant
Adds the contributor-facing scaffolding the repo was missing and some lightweight automation to keep PR review sustainable as contribution volume grows.
What's here
.github/pull_request_template.md) surfacing the existing CONTRIBUTING rules at PR time: linked issue, focused scope, tests, fmt/clippy, conventional commits, plus a protocol-and-signing checklist for changes that touch identity, signatures, UCAN, or wire formats.SECURITY.mdinstead of the public tracker.Notes for reviewers
needs-issue/needs-descriptionand never touches issues orworkflow-changePRs. It warns at 14 days and closes 7 days later; closed PRs can be reopened any time.pull_request(notpull_request_target), never checks out or runs PR code, never interpolates PR text into a shell, pins both actions by commit SHA, and uses least-privilege permissions.Summary by CodeRabbit
Documentation
Chores