feat: automate CodeRabbit plan for intermediate/advanced issues (#1289) #1332
Conversation
📝 WalkthroughWalkthroughAdds a GitHub Actions workflow and a Node.js helper script that detect issues labeled "intermediate" or "advanced", deduplicate via recent comments, and post a stable marker comment to trigger CodeRabbit's plan feature; includes payload validation, pagination, error handling, and concise logging. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant GitHubEvents as GitHub Events
participant Workflow as Actions Workflow
participant Script as coderabbit_plan_trigger.js
participant GHAPI as GitHub REST API
participant CodeRabbit as CodeRabbit Plan
GitHubEvents->>Workflow: issues event (opened | labeled)
Workflow->>Script: run via actions/github-script (provides `github`, `context`)
Script->>Script: validate payload & detect label (intermediate/advanced)
alt No matching label
Script-->>Workflow: exit (no-op)
else Matching label found
Script->>GHAPI: list issue comments (paged, up to ~500)
GHAPI-->>Script: return comments
alt Plan marker present
Script-->>Workflow: exit (already triggered)
else No marker found
Script->>GHAPI: create issue comment (stable marker to trigger plan)
GHAPI->>CodeRabbit: comment triggers plan mode
CodeRabbit-->>GHAPI: plan initiation acknowledged
Script->>Script: log summary (repo, issue#, title, labels)
Script-->>Workflow: finish
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
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: 5
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
.github/scripts/coderabbit_plan_trigger.js.github/workflows/bot-coderabbit-plan-trigger.ymlCHANGELOG.md
🧰 Additional context used
📓 Path-based instructions (2)
.github/scripts/**/*.js
⚙️ CodeRabbit configuration file
.github/scripts/**/*.js: Review JavaScript scripts as long-lived automation code.Scripts must remain:
Focused
Readable
Purpose-built
All
context.payloadfields MUST be validatedFree-form text MUST NOT be trusted
Dynamic code execution is prohibited
Avoid
child_process.exec; preferexecFileif neededAll async operations MUST be wrapped in try/catch
Errors MUST include contextual metadata
Duplicate API calls MUST be avoided
Marker-based deduplication is required
Scripts MUST NOT assume write access
Permission failures MUST be handled gracefully
Files:
.github/scripts/coderabbit_plan_trigger.js
.github/workflows/**/*
⚙️ CodeRabbit configuration file
.github/workflows/**/*: Review workflows as security-sensitive infrastructure.A good workflow is small, focused, and boring.
If a workflow is clever, generic, or overly flexible, it is a risk.
PRIORITY 0 — ABSOLUTE REQUIREMENTS
- All third-party actions MUST be pinned to full commit SHAs, similar to other workflows.
permissions:MUST be explicitly declared and minimally scoped.- Workflows MUST behave safely when executed from forks.
- YAML MUST orchestrate steps, not implement business logic.
- Any workflow that mutates GitHub state MUST support dry-run mode.
- Dry-run behavior must be explicit and visible in logs.
- Workflows MUST NOT modify repository source code outside
.github/.
PRIORITY 1 — SCOPE, FOCUS & RESTRAINT
- The title of each workflow must be relevant, match similar naming schemes, and match its script filename.
- Each workflow MUST have a single, clearly defined objective and SHOULD document this in a top-level comment.
- Flag workflows that:
- Attempt to be generic “frameworks”
- Include speculative or future-facing logic
- Perform actions unrelated to the stated goal
- Over-abstraction and excess flexibility are maintenance risks.
PRIORITY 2 — INPUT HARDENING
- Treat ALL GitHub event data as potentially hostile input, including:
- issue titles, bodies, and comments
- labels, usernames, branch names
- Free-form user input MUST NOT be passed directly into:
- shell commands
- gh CLI arguments
- Node.js exec / spawn calls
- Require strict allowlists or exact string matches.
- Flag any use of:
- eval or bash -c
- backticks or $(...) with user-controlled input
------------------...
Files:
.github/workflows/bot-coderabbit-plan-trigger.yml
🧬 Code graph analysis (1)
.github/scripts/coderabbit_plan_trigger.js (1)
.github/scripts/pr_inactivity_reminder.js (2)
owner(77-77)repo(78-78)
🪛 LanguageTool
CHANGELOG.md
[uncategorized] ~23-~23: The official name of this software platform is spelled with a capital “H”.
Context: ...matter for consistent code style - Added `.github/workflows/bot-coderabbit-plan-trigger.y...
(GITHUB)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (2)
CHANGELOG.md (1)
23-23: LGTM! Changelog entry is clear and follows conventions.The entry accurately documents the new workflow and its purpose. The static analysis hint about capitalizing "GitHub" is a false positive—
.github/workflows/is a literal directory path and should remain lowercase..github/scripts/coderabbit_plan_trigger.js (1)
23-63: LGTM! Well-structured error handling and validation.The script demonstrates good practices:
- Comprehensive input validation (lines 29, 32-41)
- Case-insensitive label matching
- Proper error handling with try/catch blocks
- Efficient pagination for comment retrieval
- Clear logging with summary output
The label validation logic correctly handles both existing issue labels and newly added labels.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
.github/workflows/bot-coderabbit-plan-trigger.yml (1)
25-32: Acknowledge past review: move label logic to script.The previous review comment suggesting to simplify this conditional remains valid. Per coding guidelines PRIORITY 4: "YAML should orchestrate execution only. All non-trivial logic MUST live in scripts."
The script already implements case-insensitive label filtering at lines 38-48, making this YAML-level check redundant and creating a maintenance burden.
Based on coding guidelines for workflows.
.github/scripts/coderabbit_plan_trigger.js (1)
55-55: Still using unreliable duplicate detection.The past review comment about inconsistent marker usage remains unaddressed. Line 55 checks for
'@coderabbitai plan'in any comment, which can produce false positives if the text appears in discussions or examples.The marker constant (line 3) exists precisely for reliable duplicate detection but isn't used here.
🔎 Proposed fix
- if (comments.some(c => c.body?.includes('@coderabbitai plan'))) { + if (comments.some(c => c.body?.includes(marker))) { return console.log(`CodeRabbit plan already triggered for #${issue.number}`); }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.github/scripts/coderabbit_plan_trigger.js.github/workflows/bot-coderabbit-plan-trigger.yml
🧰 Additional context used
📓 Path-based instructions (2)
.github/workflows/**/*
⚙️ CodeRabbit configuration file
.github/workflows/**/*: Review workflows as security-sensitive infrastructure.A good workflow is small, focused, and boring.
If a workflow is clever, generic, or overly flexible, it is a risk.
PRIORITY 0 — ABSOLUTE REQUIREMENTS
- All third-party actions MUST be pinned to full commit SHAs, similar to other workflows.
permissions:MUST be explicitly declared and minimally scoped.- Workflows MUST behave safely when executed from forks.
- YAML MUST orchestrate steps, not implement business logic.
- Any workflow that mutates GitHub state MUST support dry-run mode.
- Dry-run behavior must be explicit and visible in logs.
- Workflows MUST NOT modify repository source code outside
.github/.
PRIORITY 1 — SCOPE, FOCUS & RESTRAINT
- The title of each workflow must be relevant, match similar naming schemes, and match its script filename.
- Each workflow MUST have a single, clearly defined objective and SHOULD document this in a top-level comment.
- Flag workflows that:
- Attempt to be generic “frameworks”
- Include speculative or future-facing logic
- Perform actions unrelated to the stated goal
- Over-abstraction and excess flexibility are maintenance risks.
PRIORITY 2 — INPUT HARDENING
- Treat ALL GitHub event data as potentially hostile input, including:
- issue titles, bodies, and comments
- labels, usernames, branch names
- Free-form user input MUST NOT be passed directly into:
- shell commands
- gh CLI arguments
- Node.js exec / spawn calls
- Require strict allowlists or exact string matches.
- Flag any use of:
- eval or bash -c
- backticks or $(...) with user-controlled input
------------------...
Files:
.github/workflows/bot-coderabbit-plan-trigger.yml
.github/scripts/**/*.js
⚙️ CodeRabbit configuration file
.github/scripts/**/*.js: Review JavaScript scripts as long-lived automation code.Scripts must remain:
Focused
Readable
Purpose-built
All
context.payloadfields MUST be validatedFree-form text MUST NOT be trusted
Dynamic code execution is prohibited
Avoid
child_process.exec; preferexecFileif neededAll async operations MUST be wrapped in try/catch
Errors MUST include contextual metadata
Duplicate API calls MUST be avoided
Marker-based deduplication is required
Scripts MUST NOT assume write access
Permission failures MUST be handled gracefully
Files:
.github/scripts/coderabbit_plan_trigger.js
🧬 Code graph analysis (1)
.github/scripts/coderabbit_plan_trigger.js (1)
.github/scripts/pr_inactivity_reminder.js (2)
owner(77-77)repo(78-78)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Codacy Static Code Analysis
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
.github/scripts/coderabbit_plan_trigger.js (3)
63-63: Still not using marker for duplicate detection.The past review comment flagged that this line should check for the
markerconstant instead of the literal string'@coderabbitai plan'. The issue was marked as addressed, but the code still checks for the literal string.This creates unreliable duplicate detection because any comment containing
@coderabbitai plan(even in unrelated context or from other users) will prevent the script from posting the trigger.🔎 Proposed fix
- if (comments.some(c => c.body?.includes('@coderabbitai plan'))) { + if (comments.some(c => c.body?.includes(marker))) { return console.log(`CodeRabbit plan already triggered for #${issue.number}`); }This ensures the check matches only comments posted by this script, not any comment mentioning
@coderabbitai plan.Based on coding guidelines requiring marker-based deduplication.
31-31: Validatecontext.repobefore destructuring.Per coding guidelines: "All
context.payloadfields MUST be validated." The script destructurescontext.repowithout checking if it exists, which could throw if the webhook payload is malformed.🔎 Proposed fix
- const { owner, repo } = context.repo; + if (!context.repo?.owner || !context.repo?.repo) { + return console.log('Invalid repository context'); + } + const { owner, repo } = context.repo;Based on coding guidelines requiring payload validation.
9-9: Consider boolean dry-run check for robustness.The string comparison
dryRun === 'true'works but is fragile. If the environment variable is set to1,yes, ortruewith different casing, it won't be recognized as dry-run mode.Consider normalizing to boolean earlier in the flow.
🔎 Proposed refactor
At line 33 where
dryRunis first assigned, normalize to boolean:- const dryRun = process.env.DRY_RUN || 'false'; + const dryRun = process.env.DRY_RUN === 'true';Then update line 9:
- if (dryRun === 'true') { + if (dryRun) {And line 75 for consistent logging:
- console.log(`Dry Run: ${dryRun}`); + console.log(`Dry Run: ${dryRun ? 'true' : 'false'}`);
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/scripts/coderabbit_plan_trigger.js
🧰 Additional context used
📓 Path-based instructions (1)
.github/scripts/**/*.js
⚙️ CodeRabbit configuration file
.github/scripts/**/*.js: Review JavaScript scripts as long-lived automation code.Scripts must remain:
Focused
Readable
Purpose-built
All
context.payloadfields MUST be validatedFree-form text MUST NOT be trusted
Dynamic code execution is prohibited
Avoid
child_process.exec; preferexecFileif neededAll async operations MUST be wrapped in try/catch
Errors MUST include contextual metadata
Duplicate API calls MUST be avoided
Marker-based deduplication is required
Scripts MUST NOT assume write access
Permission failures MUST be handled gracefully
Files:
.github/scripts/coderabbit_plan_trigger.js
🧬 Code graph analysis (1)
.github/scripts/coderabbit_plan_trigger.js (1)
.github/scripts/pr_inactivity_reminder.js (2)
owner(77-77)repo(78-78)
🪛 GitHub Check: Codacy Static Code Analysis
.github/scripts/coderabbit_plan_trigger.js
[warning] 29-29: .github/scripts/coderabbit_plan_trigger.js#L29
Method module.exports has a cyclomatic complexity of 10 (limit is 8)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (2)
.github/scripts/coderabbit_plan_trigger.js (2)
67-75: LGTM!The trigger invocation and summary logging provide clear feedback about the script's execution, including repository, issue details, and dry-run status.
29-79: Cyclomatic complexity is acceptable for this use case.Static analysis flags complexity of 10, but the function follows a clear linear flow: validate → check labels → check duplicates → trigger → log. Breaking it into smaller functions would add indirection without meaningful benefit.
The current structure is readable and maintainable for this automation script.
|
Hi, this is MergeConflictBot. Please resolve these conflicts locally and push the changes. To assist you, please read: Thank you for contributing! |
Mounil2005
force-pushed
the
feature/coderabbit-plan-for-intermediate-issues
branch
from
837ad58 to
6b3ec2e
Compare
Mounil2005
force-pushed
the
feature/coderabbit-plan-for-intermediate-issues
branch
2 times, most recently
from
7504457 to
276b104
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
.github/workflows/bot-coderabbit-plan-trigger.yml (1)
15-17: Concurrency group breaks if workflow_dispatch is used.The concurrency group uses
github.event.issue.number, which is undefined forworkflow_dispatchevents. This would cause all manual dispatch runs to share the groupcoderabbit-plan-, blocking each other.If you remove
workflow_dispatchas suggested above, this issue is resolved. Otherwise, usegithub.event.issue.number || github.run_idto handle both event types.🔎 Proposed fix (if keeping workflow_dispatch)
concurrency: - group: coderabbit-plan-${{ github.event.issue.number }} + group: coderabbit-plan-${{ github.event.issue.number || github.run_id }} cancel-in-progress: falseBased on coding guidelines for workflows.
.github/scripts/coderabbit_plan_trigger.js (1)
55-55: Consider using the marker for more reliable duplicate detection.The current check
c.body?.includes('@coderabbitai plan')could produce false positives if someone mentions@coderabbitai planin an unrelated comment. Using the marker would ensure detection is limited to comments posted by this script.This was previously flagged and marked as resolved, but the code still uses the broader check. If this was intentional, no action needed.
🔎 Proposed refinement
- return comments.some(c => c.body?.includes('@coderabbitai plan')); + return comments.some(c => c.body?.includes(marker));The marker is defined at line 3 and included in the comment at line 6, so this would work correctly.
Based on past review discussion.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
.github/scripts/coderabbit_plan_trigger.js.github/workflows/bot-coderabbit-plan-trigger.ymlCHANGELOG.md
🧰 Additional context used
📓 Path-based instructions (2)
.github/workflows/**/*
⚙️ CodeRabbit configuration file
.github/workflows/**/*: Review workflows as security-sensitive infrastructure.A good workflow is small, focused, and boring.
If a workflow is clever, generic, or overly flexible, it is a risk.
PRIORITY 0 — ABSOLUTE REQUIREMENTS
- All third-party actions MUST be pinned to full commit SHAs, similar to other workflows.
permissions:MUST be explicitly declared and minimally scoped.- Workflows MUST behave safely when executed from forks.
- YAML MUST orchestrate steps, not implement business logic.
- Any workflow that mutates GitHub state MUST support dry-run mode.
- Dry-run behavior must be explicit and visible in logs.
- Workflows MUST NOT modify repository source code outside
.github/.
PRIORITY 1 — SCOPE, FOCUS & RESTRAINT
- The title of each workflow must be relevant, match similar naming schemes, and match its script filename.
- Each workflow MUST have a single, clearly defined objective and SHOULD document this in a top-level comment.
- Flag workflows that:
- Attempt to be generic “frameworks”
- Include speculative or future-facing logic
- Perform actions unrelated to the stated goal
- Over-abstraction and excess flexibility are maintenance risks.
PRIORITY 2 — INPUT HARDENING
- Treat ALL GitHub event data as potentially hostile input, including:
- issue titles, bodies, and comments
- labels, usernames, branch names
- Free-form user input MUST NOT be passed directly into:
- shell commands
- gh CLI arguments
- Node.js exec / spawn calls
- Require strict allowlists or exact string matches.
- Flag any use of:
- eval or bash -c
- backticks or $(...) with user-controlled input
------------------...
Files:
.github/workflows/bot-coderabbit-plan-trigger.yml
.github/scripts/**/*.js
⚙️ CodeRabbit configuration file
.github/scripts/**/*.js: Review JavaScript scripts as long-lived automation code.Scripts must remain:
Focused
Readable
Purpose-built
All
context.payloadfields MUST be validatedFree-form text MUST NOT be trusted
Dynamic code execution is prohibited
Avoid
child_process.exec; preferexecFileif neededAll async operations MUST be wrapped in try/catch
Errors MUST include contextual metadata
Duplicate API calls MUST be avoided
Marker-based deduplication is required
Scripts MUST NOT assume write access
Permission failures MUST be handled gracefully
Files:
.github/scripts/coderabbit_plan_trigger.js
🧬 Code graph analysis (1)
.github/scripts/coderabbit_plan_trigger.js (2)
.github/scripts/pr_inactivity_reminder.js (2)
owner(77-77)repo(78-78).github/scripts/bot-gfi-assign-on-comment.js (1)
issueNumber(170-170)
🪛 LanguageTool
CHANGELOG.md
[uncategorized] ~24-~24: The official name of this software platform is spelled with a capital “H”.
Context: ...matter for consistent code style - Added `.github/workflows/bot-coderabbit-plan-trigger.y...
(GITHUB)
🔇 Additional comments (4)
CHANGELOG.md (1)
23-24: LGTM! Changelog entry is clear and well-documented.The entry properly documents the new automation workflow and links to the relevant issue. The static analysis hint about "GitHub" capitalization is a false positive—
.github/is the correct literal directory name..github/workflows/bot-coderabbit-plan-trigger.yml (1)
1-2: Workflow structure follows repository conventions.The workflow properly:
- Uses security hardening with pinned action SHAs
- Declares minimal permissions (issues: write, contents: read)
- Implements concurrency control
- Delegates business logic to a separate script
- Includes clear comments explaining behavior
Based on coding guidelines for workflows.
Also applies to: 28-44
.github/scripts/coderabbit_plan_trigger.js (2)
41-56: Pagination handling follows best practices.The implementation properly:
- Uses
paginate.iteratorfor controlled iteration- Enforces a hard upper bound of 500 comments
- Prevents unbounded API calls on high-traffic issues
Based on coding guidelines PRIORITY 5 (API efficiency).
29-39: Script structure is clean and well-organized.The script demonstrates good practices:
- Clear separation of concerns with helper functions
- Proper validation of payload data
- Case-insensitive label matching
- Comprehensive error handling with try/catch
- Useful logging for debugging and operation tracking
Also applies to: 67-91
Mounil2005
force-pushed
the
feature/coderabbit-plan-for-intermediate-issues
branch
2 times, most recently
from
1da16e2 to
da4f6e9
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/scripts/coderabbit_plan_trigger.js (1)
49-49: Still checking hardcoded string instead of marker.Despite past review comments indicating this was addressed, line 49 still checks for the hardcoded string
'@coderabbitai plan'instead of using themarkerconstant defined at line 3. This creates unreliable duplicate detection—any comment containing@coderabbitai plan(even in unrelated context) will prevent the script from posting.🔎 Proposed fix
- return comments.some(c => c.body?.includes('@coderabbitai plan')); + return comments.some(c => c.body?.includes(marker));This ensures the check matches only comments posted by this script (those containing the unique marker), not any arbitrary mention of
@coderabbitai plan.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.github/scripts/coderabbit_plan_trigger.js.github/workflows/bot-coderabbit-plan-trigger.yml
🧰 Additional context used
📓 Path-based instructions (2)
.github/workflows/**/*
⚙️ CodeRabbit configuration file
.github/workflows/**/*: Review workflows as security-sensitive infrastructure.A good workflow is small, focused, and boring.
If a workflow is clever, generic, or overly flexible, it is a risk.
PRIORITY 0 — ABSOLUTE REQUIREMENTS
- All third-party actions MUST be pinned to full commit SHAs, similar to other workflows.
permissions:MUST be explicitly declared and minimally scoped.- Workflows MUST behave safely when executed from forks.
- YAML MUST orchestrate steps, not implement business logic.
- Any workflow that mutates GitHub state MUST support dry-run mode.
- Dry-run behavior must be explicit and visible in logs.
- Workflows MUST NOT modify repository source code outside
.github/.
PRIORITY 1 — SCOPE, FOCUS & RESTRAINT
- The title of each workflow must be relevant, match similar naming schemes, and match its script filename.
- Each workflow MUST have a single, clearly defined objective and SHOULD document this in a top-level comment.
- Flag workflows that:
- Attempt to be generic “frameworks”
- Include speculative or future-facing logic
- Perform actions unrelated to the stated goal
- Over-abstraction and excess flexibility are maintenance risks.
PRIORITY 2 — INPUT HARDENING
- Treat ALL GitHub event data as potentially hostile input, including:
- issue titles, bodies, and comments
- labels, usernames, branch names
- Free-form user input MUST NOT be passed directly into:
- shell commands
- gh CLI arguments
- Node.js exec / spawn calls
- Require strict allowlists or exact string matches.
- Flag any use of:
- eval or bash -c
- backticks or $(...) with user-controlled input
------------------...
Files:
.github/workflows/bot-coderabbit-plan-trigger.yml
.github/scripts/**/*.js
⚙️ CodeRabbit configuration file
.github/scripts/**/*.js: Review JavaScript scripts as long-lived automation code.Scripts must remain:
Focused
Readable
Purpose-built
All
context.payloadfields MUST be validatedFree-form text MUST NOT be trusted
Dynamic code execution is prohibited
Avoid
child_process.exec; preferexecFileif neededAll async operations MUST be wrapped in try/catch
Errors MUST include contextual metadata
Duplicate API calls MUST be avoided
Marker-based deduplication is required
Scripts MUST NOT assume write access
Permission failures MUST be handled gracefully
Files:
.github/scripts/coderabbit_plan_trigger.js
🧬 Code graph analysis (1)
.github/scripts/coderabbit_plan_trigger.js (2)
.github/scripts/pr_inactivity_reminder.js (2)
owner(77-77)repo(78-78).github/scripts/bot-gfi-assign-on-comment.js (1)
issueNumber(170-170)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (8)
.github/scripts/coderabbit_plan_trigger.js (4)
5-21: LGTM!The function correctly posts the CodeRabbit plan trigger comment with proper error handling and logging. The removal of dry-run logic aligns with maintainer feedback.
23-33: LGTM!The case-insensitive label detection correctly handles both existing issue labels and the newly added label, with proper null-safety using optional chaining.
52-58: LGTM!The summary logging provides useful context for debugging and monitoring, with proper null-safety for optional fields.
60-83: LGTM!The main entry point properly validates the payload, performs all necessary checks in the correct order, and includes comprehensive error handling. The logic flow is clear and follows the intended workflow.
.github/workflows/bot-coderabbit-plan-trigger.yml (4)
8-10: LGTM!Permissions are minimally scoped:
issues: writefor posting comments andcontents: readfor repository checkout. This follows the principle of least privilege.
12-26: LGTM!The job configuration is appropriate:
- The concurrency group ensures only one plan trigger runs per issue at a time, preventing race conditions.
cancel-in-progress: falseis correct since we want all duplicate checks to complete.- The case-insensitive label matching in YAML, while verbose, prevents unnecessary workflow notifications (as explained by the maintainer).
29-32: LGTM!The harden-runner step is properly configured with full commit SHA pinning and follows the repository's security hardening pattern.
34-44: LGTM!The checkout and script execution steps are properly configured:
- All third-party actions are pinned to full commit SHAs as required by coding guidelines.
- The script path is correct and matches the repository structure.
- The
GITHUB_TOKENand required parameters are properly passed to the script.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.github/scripts/coderabbit_plan_trigger.js.github/workflows/bot-coderabbit-plan-trigger.yml
🧰 Additional context used
📓 Path-based instructions (2)
.github/scripts/**/*.js
⚙️ CodeRabbit configuration file
.github/scripts/**/*.js: Review JavaScript scripts as long-lived automation code.Scripts must remain:
Focused
Readable
Purpose-built
All
context.payloadfields MUST be validatedFree-form text MUST NOT be trusted
Dynamic code execution is prohibited
Avoid
child_process.exec; preferexecFileif neededAll async operations MUST be wrapped in try/catch
Errors MUST include contextual metadata
Duplicate API calls MUST be avoided
Marker-based deduplication is required
Scripts MUST NOT assume write access
Permission failures MUST be handled gracefully
Files:
.github/scripts/coderabbit_plan_trigger.js
.github/workflows/**/*
⚙️ CodeRabbit configuration file
.github/workflows/**/*: Review workflows as security-sensitive infrastructure.A good workflow is small, focused, and boring.
If a workflow is clever, generic, or overly flexible, it is a risk.
PRIORITY 0 — ABSOLUTE REQUIREMENTS
- All third-party actions MUST be pinned to full commit SHAs, similar to other workflows.
permissions:MUST be explicitly declared and minimally scoped.- Workflows MUST behave safely when executed from forks.
- YAML MUST orchestrate steps, not implement business logic.
- Any workflow that mutates GitHub state MUST support dry-run mode.
- Dry-run behavior must be explicit and visible in logs.
- Workflows MUST NOT modify repository source code outside
.github/.
PRIORITY 1 — SCOPE, FOCUS & RESTRAINT
- The title of each workflow must be relevant, match similar naming schemes, and match its script filename.
- Each workflow MUST have a single, clearly defined objective and SHOULD document this in a top-level comment.
- Flag workflows that:
- Attempt to be generic “frameworks”
- Include speculative or future-facing logic
- Perform actions unrelated to the stated goal
- Over-abstraction and excess flexibility are maintenance risks.
PRIORITY 2 — INPUT HARDENING
- Treat ALL GitHub event data as potentially hostile input, including:
- issue titles, bodies, and comments
- labels, usernames, branch names
- Free-form user input MUST NOT be passed directly into:
- shell commands
- gh CLI arguments
- Node.js exec / spawn calls
- Require strict allowlists or exact string matches.
- Flag any use of:
- eval or bash -c
- backticks or $(...) with user-controlled input
------------------...
Files:
.github/workflows/bot-coderabbit-plan-trigger.yml
🧬 Code graph analysis (1)
.github/scripts/coderabbit_plan_trigger.js (2)
.github/scripts/pr_inactivity_reminder.js (2)
owner(77-77)repo(78-78).github/scripts/bot-gfi-assign-on-comment.js (1)
issueNumber(170-170)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (2)
.github/scripts/coderabbit_plan_trigger.js (1)
1-83: Excellent implementation—follows coding guidelines comprehensively.The script demonstrates strong adherence to the coding guidelines:
- All
context.payloadfields properly validated with optional chaining- Pagination bounded with a hard 500-comment limit
- Comprehensive error handling with try/catch at both function and module levels
- Marker-based duplicate prevention
- No security risks (no dynamic execution, no shell commands, no unvalidated user input in dangerous contexts)
- Clear, focused logging throughout
The helper functions are well-structured, and the main flow is easy to follow. Past review iterations have addressed all significant concerns (dry-run removal per maintainer request, pagination bounds, error handling, etc.).
.github/workflows/bot-coderabbit-plan-trigger.yml (1)
1-43: Workflow implementation is solid and follows security guidelines.The workflow demonstrates strong adherence to the coding guidelines:
- Security: All third-party actions pinned to full commit SHAs (lines 29, 34, 39)
- Permissions: Explicitly declared and minimally scoped—
issues: writefor posting comments,contents: readfor checkout- Concurrency: Proper concurrency group prevents race conditions on the same issue (lines 14-16)
- Focus: Single, clear objective with descriptive top-level comment
- Safe operation: No source code modifications, safe for fork execution
The label-matching logic in the
ifcondition (lines 18-25) duplicates the script's validation, but per maintainer feedback, this YAML-level filtering prevents unwanted email notifications when the workflow skips execution.
Mounil2005
force-pushed
the
feature/coderabbit-plan-for-intermediate-issues
branch
2 times, most recently
from
ced562b to
e17756e
Compare
MonaaEid
left a comment
MonaaEid
left a comment
There was a problem hiding this comment.
Please share the test link you created in your fork and make sure your changelog entry is listed as the last item in the Added section
exploreriii
left a comment
exploreriii
left a comment
There was a problem hiding this comment.
Please test if an automated message can trigger code rabbit
A human can ask it to plan, but does a bot qualify or will it guard against that?
…o-ledger#1289) Signed-off-by: Mounil <[email protected]>
Signed-off-by: Mounil <[email protected]>
Signed-off-by: Mounil <[email protected]>
Signed-off-by: Mounil <[email protected]>
Signed-off-by: Mounil <[email protected]>
Mounil2005
force-pushed
the
feature/coderabbit-plan-for-intermediate-issues
branch
from
e17756e to
4d60a6b
Compare
|
https://github.com/Mounil2005/hiero-sdk-python/issues Everything is working as expected! |
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #1332 +/- ##
=======================================
Coverage 92.29% 92.29%
=======================================
Files 139 139
Lines 8515 8515
=======================================
Hits 7859 7859
Misses 656 656 🚀 New features to boost your workflow:
|
3 participants
Description:
Automate CodeRabbit plan generation for intermediate and advanced issues to help contributors assess complexity and understand implementation requirements
Related issue(s):
Fixes #1289
Notes for reviewer:
The workflow triggers on both issue creation and labeling events to handle template-created issues and manually labeled issues. It includes comprehensive duplicate prevention to avoid spamming @coderabbitai plan comments. Case-insensitive label filtering ensures robustness against label case variations.
Checklist