[feature] Added issue autoassignment bots#1264
Open
Eeshu-Yadav wants to merge 3 commits intoopenwisp:masterfrom
Open
[feature] Added issue autoassignment bots#1264Eeshu-Yadav wants to merge 3 commits intoopenwisp:masterfrom
Eeshu-Yadav wants to merge 3 commits intoopenwisp:masterfrom
Conversation
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds four GitHub Actions workflows that invoke the openwisp-utils bot for: issue auto-assignment on comments, PR↔issue auto-assignment on PR events, PR reopen reassignment, and stale PR management. Workflows trigger on issue_comment, pull_request_target, schedule, and workflow_dispatch; they call a reusable workflow in openwisp/openwisp-utils and forward a bot_command plus GitHub App credentials via secrets. Concurrency and permission scopes are defined per workflow and some jobs conditionally run based on event action or whether the event is a PR. Sequence Diagram(s)sequenceDiagram
participant GitHub as GitHub Events
participant Runner as Actions Runner
participant ReusableWF as openwisp-utils Reusable Workflow
participant GitHubAPI as GitHub API
GitHub->>Runner: trigger workflow (issue_comment / pull_request_target / schedule / workflow_dispatch)
Runner->>ReusableWF: invoke reusable workflow (bot_command, secrets: OPENWISP_BOT_APP_ID, OPENWISP_BOT_PRIVATE_KEY)
ReusableWF->>GitHubAPI: create App token / call GitHub API (assign/unassign/link PRs)
GitHubAPI-->>ReusableWF: API responses
ReusableWF-->>Runner: complete job
Runner-->>GitHub: workflow result
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related issues
Suggested reviewers
🚥 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)
📝 Coding Plan
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 |
Code Review SummaryStatus: No New Issues Found | Recommendation: Address existing comments The PR adds 4 GitHub Actions workflows for automated issue/PR assignment. Existing comments have already identified the key concerns:
These are the main issues to address before merge. Files Reviewed (4 files)
|
There was a problem hiding this comment.
Pull request overview
This PR introduces several GitHub Actions workflows that run OpenWISP automation bots (sourced from openwisp/openwisp-utils) to manage issue auto-assignment and PR lifecycle automation across the repository.
Changes:
- Add an issue comment-driven workflow to handle issue assignment requests.
- Add PR workflows to link/unlink issues and to reassign on PR reopen / handle PR activity.
- Add a scheduled workflow to manage stale PRs.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| .github/workflows/bot-autoassign-stale-pr.yml | Scheduled job to run the stale PR management bot from openwisp-utils. |
| .github/workflows/bot-autoassign-pr-reopen.yml | Runs bot logic on PR reopen and on PR comment activity. |
| .github/workflows/bot-autoassign-pr-issue-link.yml | Runs bot logic on PR opened/reopened/closed to manage PR↔issue assignment/linking behavior. |
| .github/workflows/bot-autoassign-issue.yml | Runs bot logic on issue comments to auto-assign issues. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
| jobs: | ||
| respond-to-assign-request: | ||
| runs-on: ubuntu-latest | ||
| if: github.event.issue.pull_request == null |
There was a problem hiding this comment.
This workflow runs on every issue_comment creation and immediately mints a GitHub App token with issues: write. Without restricting by comment.body (e.g., a specific command) and/or comment.author_association (member/collaborator), any external user can trigger privileged bot activity and cause unnecessary runs/spam. Add an if: guard similar to .github/workflows/backport.yml (which checks association and command) so only intended requests execute.
Suggested change
| if: github.event.issue.pull_request == null | |
| if: > | |
| github.event.issue.pull_request == null && | |
| contains(github.event.comment.body, '/assign-me') && | |
| ( | |
| github.event.comment.author_association == 'MEMBER' || | |
| github.event.comment.author_association == 'OWNER' || | |
| github.event.comment.author_association == 'COLLABORATOR' | |
| ) |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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/bot-autoassign-issue.yml:
- Around line 16-18: The respond-to-assign-request job currently runs for every
non-PR issue event and fails when openwisp-utils' issue_assignment bot returns
non-zero for ordinary comments; restrict execution by adding a prefilter on the
issue comment body (e.g., require a regex or specific command like "/assign" or
"assign me") in the job-level if so the job only runs when
github.event.comment.body matches the assignment trigger; update the if
condition used in respond-to-assign-request (which currently uses
github.event.issue.pull_request == null) to include the body-match check before
invoking issue_assignment.
In @.github/workflows/bot-autoassign-pr-issue-link.yml:
- Around line 4-5: The workflow bot-autoassign-pr-issue-link.yml currently lists
the pull_request_target event types including "reopened", which causes duplicate
concurrent runs with bot-autoassign-pr-reopen.yml; remove "reopened" from the
types array in the pull_request_target trigger (leave "opened" and "closed") so
only bot-autoassign-pr-reopen.yml handles reopen events, ensuring
reopen-specific logic and concurrency groups are not duplicated.
In @.github/workflows/bot-autoassign-pr-reopen.yml:
- Around line 23-28: The GitHub App token created by the generate-token step
(uses: actions/create-github-app-token@v2) is not downscoped and therefore
inherits all installation permissions; update the generate-token step to include
explicit permission-* inputs to limit the token to the minimum required scopes
for this bot (e.g., permission-issues, permission-pull-requests,
permission-checks as appropriate for the workflow’s actions). Edit the step with
id generate-token to add only the specific permission-* entries needed by the
workflow so the app token no longer grants broad access.
- Around line 54-56: The job handle-pr-activity is currently triggered for every
issue_comment (github.event_name == 'issue_comment' &&
github.event.issue.pull_request) and fails on normal review comments because
PRActivityBot returns non-zero for no-op cases; tighten the condition to only
run for the bot/commands you care about — for example add an extra check like
github.event.comment.user.login == 'pr_reopen' or restrict to comments matching
a command (e.g. contains('/reopen')) so handle-pr-activity only executes when
the pr_reopen bot/command is invoked, or alternatively coordinate with
PRActivityBot (PRActivityBot/PRActivityBot.run) to make no-op returns exit 0.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: c7db4d0f-d837-48d9-bb49-1691914610c8
📒 Files selected for processing (4)
.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml
📜 Review details
⏰ 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). (12)
- GitHub Check: Upload results
- GitHub Check: Python==3.11 | django~=4.2.0
- GitHub Check: Python==3.13 | django~=5.1.0
- GitHub Check: Python==3.12 | django~=5.2.0
- GitHub Check: Python==3.12 | django~=5.1.0
- GitHub Check: Python==3.13 | django~=5.2.0
- GitHub Check: Python==3.12 | django~=4.2.0
- GitHub Check: Python==3.11 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=5.1.0
- GitHub Check: Python==3.10 | django~=5.2.0
- GitHub Check: Python==3.10 | django~=5.1.0
- GitHub Check: Python==3.10 | django~=4.2.0
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:31.829Z
Learning: Repository: openwisp/openwisp-controller
File/Area: .github/workflows/backport.yml (backport-on-comment condition)
Learning: Project policy is to restrict the backport trigger via issue comments to users with author_association "MEMBER" or "OWNER" only; "COLLABORATOR" is intentionally excluded (per maintainer feedback on PR `#1233`).
📚 Learning: 2026-02-24T16:25:20.080Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:20.080Z
Learning: In .github/workflows/backport.yml, enforce that backport-on-comment triggers only for users with author_association MEMBE R or OWNER (COLLABORATOR excluded), reflecting maintainer feedback. Update the trigger condition to check author_association and restrict to MEMBERS/OWNERS; document rationale and PR `#1233` reference in code comments.
Applied to files:
.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-pr-issue-link.yml
📚 Learning: 2026-02-24T16:24:55.443Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:22-22
Timestamp: 2026-02-24T16:24:55.443Z
Learning: In repositories within the OpenWISP organization, it is acceptable to reference reusable workflows from other OpenWISP-controlled repos using mutable refs (e.g., master) in .github/workflows. This is permissible due to the shared trust boundary within the organization. If applying this pattern, ensure the target repos are under the same organization and maintain awareness of potential breakages from upstream mutable refs; consider pinning to a tagged version for longer-term stability when appropriate.
Applied to files:
.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-pr-issue-link.yml
Eeshu-Yadav
force-pushed
the
feature/bot-autoassign
branch
2 times, most recently
from
3e0ed3c to
cbc7043
Compare
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (3)
.github/workflows/bot-autoassign-issue.yml (1)
16-18:⚠️ Potential issue | 🟠 MajorLine 18 still runs the bot for ordinary issue discussion.
The only guard here is “not a PR”, so any new issue comment invokes the upstream assignment bot. Its no-op path is treated as failure, which will keep turning normal discussions red unless you prefilter the comment body before dispatching the job.
#!/bin/bash set -euo pipefail echo "--- issue_assignment bot implementation ---" curl -fsSL https://raw.githubusercontent.com/openwisp/openwisp-utils/master/.github/actions/bot-autoassign/issue_assignment_bot.py \ | nl -ba | sed -n '1,320p' echo echo "--- shared entrypoint ---" curl -fsSL https://raw.githubusercontent.com/openwisp/openwisp-utils/master/.github/actions/bot-autoassign/__main__.py \ | nl -ba | sed -n '1,200p'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-issue.yml around lines 16 - 18, The job respond-to-assign-request currently runs for any non-PR issue event; change its if condition to only run for issue comments containing the bot trigger and for issue_comment events (e.g. if: github.event_name == 'issue_comment' && github.event.issue.pull_request == null && contains(github.event.comment.body, '/assign') ) so ordinary discussion comments are skipped before dispatching the bot; update the if expression on the respond-to-assign-request job accordingly to prefilter by event type and comment body (use github.event.comment.body and contains) so the no-op path is not executed for general issue threads..github/workflows/bot-autoassign-pr-issue-link.yml (1)
4-5:⚠️ Potential issue | 🟠 MajorDrop
reopenedfrom this workflow.Line 5 overlaps the dedicated PR-reopen workflow, so a reopened PR will dispatch two different bots against the same linked issues. Because the concurrency groups are different, neither run suppresses the other.
✂️ Minimal fix
on: pull_request_target: - types: [opened, reopened, closed] + types: [opened, closed]#!/bin/bash set -euo pipefail echo "--- local workflow triggers ---" nl -ba .github/workflows/bot-autoassign-pr-issue-link.yml | sed -n '1,80p' echo nl -ba .github/workflows/bot-autoassign-pr-reopen.yml | sed -n '1,120p' echo echo "--- upstream issue_assignment behavior ---" curl -fsSL https://raw.githubusercontent.com/openwisp/openwisp-utils/master/.github/actions/bot-autoassign/issue_assignment_bot.py \ | grep -nE 'reopen|assign|linked|comment|close' || true echo echo "--- upstream pr_reopen behavior ---" curl -fsSL https://raw.githubusercontent.com/openwisp/openwisp-utils/master/.github/actions/bot-autoassign/pr_reopen_bot.py \ | grep -nE 'reopen|assign|linked|comment|stale' || true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-issue-link.yml around lines 4 - 5, The workflow's pull_request_target trigger includes a redundant "reopened" event which causes duplicate runs; edit the pull_request_target types array in the workflow (the entry with pull_request_target and types) to remove "reopened" so it only lists the intended events (e.g., ["opened","closed"]), ensuring reopened PRs are handled by the dedicated PR-reopen workflow..github/workflows/bot-autoassign-pr-reopen.yml (1)
54-56:⚠️ Potential issue | 🟠 MajorLine 56 still triggers this job on every PR comment.
That is too broad for the upstream
pr_reopencomment handler: routine review discussion hits the workflow even when there is nothing to do, and those no-op paths currently fail the run. Tighten theif:so this job only runs for the specific PR-author/stale-comment case you want to support.#!/bin/bash set -euo pipefail echo "--- pr_reopen bot implementation ---" curl -fsSL https://raw.githubusercontent.com/openwisp/openwisp-utils/master/.github/actions/bot-autoassign/pr_reopen_bot.py \ | nl -ba | sed -n '1,260p' echo echo "--- shared entrypoint ---" curl -fsSL https://raw.githubusercontent.com/openwisp/openwisp-utils/master/.github/actions/bot-autoassign/__main__.py \ | nl -ba | sed -n '1,200p'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-reopen.yml around lines 54 - 56, The job condition on handle-pr-activity is too broad and runs on every PR comment; tighten the if: by requiring both that the comment body matches the specific trigger text (e.g., check github.event.comment.body contains the pr_reopen/stale-comment token you expect) and that the commenter is the PR author (compare github.event.comment.user.login to github.event.pull_request.user.login), so update the handle-pr-activity if: expression to combine these two checks instead of only github.event_name == 'issue_comment' && github.event.issue.pull_request.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/bot-autoassign-issue.yml:
- Around line 16-18: The job respond-to-assign-request currently runs for any
non-PR issue event; change its if condition to only run for issue comments
containing the bot trigger and for issue_comment events (e.g. if:
github.event_name == 'issue_comment' && github.event.issue.pull_request == null
&& contains(github.event.comment.body, '/assign') ) so ordinary discussion
comments are skipped before dispatching the bot; update the if expression on the
respond-to-assign-request job accordingly to prefilter by event type and comment
body (use github.event.comment.body and contains) so the no-op path is not
executed for general issue threads.
In @.github/workflows/bot-autoassign-pr-issue-link.yml:
- Around line 4-5: The workflow's pull_request_target trigger includes a
redundant "reopened" event which causes duplicate runs; edit the
pull_request_target types array in the workflow (the entry with
pull_request_target and types) to remove "reopened" so it only lists the
intended events (e.g., ["opened","closed"]), ensuring reopened PRs are handled
by the dedicated PR-reopen workflow.
In @.github/workflows/bot-autoassign-pr-reopen.yml:
- Around line 54-56: The job condition on handle-pr-activity is too broad and
runs on every PR comment; tighten the if: by requiring both that the comment
body matches the specific trigger text (e.g., check github.event.comment.body
contains the pr_reopen/stale-comment token you expect) and that the commenter is
the PR author (compare github.event.comment.user.login to
github.event.pull_request.user.login), so update the handle-pr-activity if:
expression to combine these two checks instead of only github.event_name ==
'issue_comment' && github.event.issue.pull_request.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 1802d2b0-fc5b-4f3c-87ae-29a8f02de91f
📒 Files selected for processing (4)
.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml
📜 Review details
⏰ 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). (11)
- GitHub Check: Python==3.10 | django~=5.1.0
- GitHub Check: Python==3.13 | django~=5.1.0
- GitHub Check: Python==3.12 | django~=5.2.0
- GitHub Check: Python==3.10 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=4.2.0
- GitHub Check: Python==3.11 | django~=5.2.0
- GitHub Check: Python==3.10 | django~=4.2.0
- GitHub Check: Python==3.11 | django~=5.1.0
- GitHub Check: Python==3.12 | django~=4.2.0
- GitHub Check: Python==3.12 | django~=5.1.0
- GitHub Check: Python==3.13 | django~=5.2.0
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:31.829Z
Learning: Repository: openwisp/openwisp-controller
File/Area: .github/workflows/backport.yml (backport-on-comment condition)
Learning: Project policy is to restrict the backport trigger via issue comments to users with author_association "MEMBER" or "OWNER" only; "COLLABORATOR" is intentionally excluded (per maintainer feedback on PR `#1233`).
📚 Learning: 2026-02-24T16:25:20.080Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:20.080Z
Learning: In .github/workflows/backport.yml, enforce that backport-on-comment triggers only for users with author_association MEMBE R or OWNER (COLLABORATOR excluded), reflecting maintainer feedback. Update the trigger condition to check author_association and restrict to MEMBERS/OWNERS; document rationale and PR `#1233` reference in code comments.
Applied to files:
.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-issue-link.yml
📚 Learning: 2026-02-24T16:24:55.443Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:22-22
Timestamp: 2026-02-24T16:24:55.443Z
Learning: In repositories within the OpenWISP organization, it is acceptable to reference reusable workflows from other OpenWISP-controlled repos using mutable refs (e.g., master) in .github/workflows. This is permissible due to the shared trust boundary within the organization. If applying this pattern, ensure the target repos are under the same organization and maintain awareness of potential breakages from upstream mutable refs; consider pinning to a tagged version for longer-term stability when appropriate.
Applied to files:
.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-issue-link.yml
📚 Learning: 2026-02-17T19:13:17.774Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: openwisp_controller/config/whois/commands.py:0-0
Timestamp: 2026-02-17T19:13:17.774Z
Learning: The openwisp-controller repository does not use Ruff as a linting tool. Do not suggest code changes based on Ruff warnings for this repository.
Applied to files:
.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-pr-issue-link.yml
📚 Learning: 2026-02-21T20:25:06.553Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: requirements.txt:20-20
Timestamp: 2026-02-21T20:25:06.553Z
Learning: The openwisp-controller project is moving away from the `~=` (compatible release) version specifier in requirements.txt because it generates too many Dependabot PRs. The preferred format is `>=X.Y.Z,<MAJOR+1.0.0` (e.g., `geoip2>=5.1.0,<6.0.0`). Do not suggest converting to `~=` format.
Applied to files:
.github/workflows/bot-autoassign-stale-pr.yml
🔇 Additional comments (1)
.github/workflows/bot-autoassign-stale-pr.yml (1)
43-49: No actionable issue. Thestale_prbot intentionally does not requireGITHUB_EVENT_NAMEor event payload because it processes all open PRs uniformly using activity-based thresholds, regardless of the trigger type (scheduleorworkflow_dispatch). TheGitHubBotbase class reads these variables but doesn't require them, andstale_pr_bot.pynever references them. This differs from event-driven bots likeissue_assignment_bot, which respond to specific interactions and need event context.
Eeshu-Yadav
force-pushed
the
feature/bot-autoassign
branch
from
cbc7043 to
7fd9020
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (4)
.github/workflows/bot-autoassign-pr-reopen.yml (2)
23-28:⚠️ Potential issue | 🟠 MajorScope the GitHub App token to minimum required permissions.
The
actions/create-github-app-token@v2action inherits all permissions granted to the app installation unless you explicitly passpermission-*inputs. The workflow'spermissions:block does not affect app tokens. Addpermission-*inputs to limit the token scope.🔧 Proposed fix for both generate-token steps
- name: Generate GitHub App token id: generate-token uses: actions/create-github-app-token@v2 with: app-id: ${{ secrets.OPENWISP_BOT_APP_ID }} private-key: ${{ secrets.OPENWISP_BOT_PRIVATE_KEY }} + permission-issues: write + permission-pull-requests: read + permission-contents: readAlso applies to: 58-63
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-reopen.yml around lines 23 - 28, The GitHub App token created by the generate-token step using actions/create-github-app-token@v2 is currently unscoped; add explicit permission-* inputs to the generate-token steps (the step with id "generate-token" that uses actions/create-github-app-token@v2) to restrict the app token to only the least-privilege permissions needed by the workflow (e.g., permission-issues, permission-pull-requests, permission-actions as appropriate); update both occurrences (the step at lines shown and the duplicate) to include the corresponding permission-* keys and values so the created token does not inherit all installation permissions.
54-56:⚠️ Potential issue | 🟠 MajorThe
handle-pr-activityjob fails on routine PR comments.The job triggers for every comment on a PR, but the upstream
PRActivityBotreturns exit code 1 (failure) when the comment isn't from the PR author or the PR lacks thestalelabel. This causes misleading red workflow runs on normal code review discussion.🔧 Proposed fix to narrow the trigger condition
Consider restricting execution to comments from the PR author or comments containing specific keywords:
handle-pr-activity: runs-on: ubuntu-latest - if: github.event_name == 'issue_comment' && github.event.issue.pull_request + if: > + github.event_name == 'issue_comment' && + github.event.issue.pull_request && + github.event.comment.user.login == github.event.issue.user.loginAlternatively, coordinate with upstream
openwisp-utilsto make no-op returns exit 0.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-reopen.yml around lines 54 - 56, The handle-pr-activity job currently runs for every PR comment and fails when PRActivityBot exits non‑zero; narrow the workflow conditional (the if on the job named handle-pr-activity) so it only runs for relevant comments — e.g., require the commenter to be the PR author by adding a check comparing github.event.comment.user.login to github.event.issue.user.login, or require specific trigger keywords by using contains(github.event.comment.body, '<keyword>') (or combine both with ||), so routine review comments don't start the job; alternatively, coordinate upstream to make PRActivityBot return 0 on no-op cases..github/workflows/bot-autoassign-issue.yml (1)
16-18:⚠️ Potential issue | 🟠 MajorOrdinary issue comments will cause workflow failures.
The job runs on every issue comment (excluding PRs), but the upstream
issue_assignmentbot returns exit code 1 when the comment doesn't contain assignment-request phrases like "assign me". This causes misleading red workflow runs on routine issue discussions.🔧 Proposed fix to prefilter comments
Add a condition to only run when the comment likely contains an assignment request:
jobs: respond-to-assign-request: runs-on: ubuntu-latest - if: github.event.issue.pull_request == null + if: > + github.event.issue.pull_request == null && + ( + contains(github.event.comment.body, 'assign me') || + contains(github.event.comment.body, 'can I work on this') || + contains(github.event.comment.body, 'I would like to work on this') + )Alternatively, coordinate with upstream
openwisp-utilsto make no-op returns exit 0.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-issue.yml around lines 16 - 18, The workflow job respond-to-assign-request currently runs for every issue comment because its if only checks that the event is an issue (github.event.issue.pull_request == null); update the job's if to also prefilter the comment body so the job runs only when the comment likely requests assignment (e.g., add a condition using github.event.comment.body and the contains/matches operator to look for phrases like "assign me", "please assign", or "assign @", e.g. github.event.comment.body matches '(?i)\\b(assign me|please assign|assign @)\\b'); keep the existing PR-exclusion check and add this additional predicate to the same if expression on the respond-to-assign-request job so ordinary comments no-op locally instead of invoking the upstream bot..github/workflows/bot-autoassign-pr-issue-link.yml (1)
4-5:⚠️ Potential issue | 🟠 MajorRemove
reopenedfrom trigger types to avoid duplicate assignment logic.Both this workflow and
bot-autoassign-pr-reopen.ymltrigger on PR reopen events with different concurrency groups, causing them to run in parallel. Each scans the PR body for linked issues and assigns them, leading to redundant runs and potentially duplicate comments.The past review marked this as "Addressed in commit 3e0ed3c" but the
reopenedtype is still present in the trigger.🔧 Proposed fix
on: pull_request_target: - types: [opened, reopened, closed] + types: [opened, closed]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-issue-link.yml around lines 4 - 5, The pull_request_target workflow currently includes "reopened" in its types array, causing duplicate runs with bot-autoassign-pr-reopen.yml; remove "reopened" from the types list in the pull_request_target trigger (i.e., change types: [opened, reopened, closed] to types: [opened, closed]) so only the dedicated reopen workflow handles reopen events, and ensure no other logic in this workflow depends on reopen events.
🤖 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/bot-autoassign-issue.yml:
- Around line 20-25: The GitHub App token creation step (id: generate-token,
uses: actions/create-github-app-token@v2) is too broad; add permission-* inputs
to downscope the token to only the permissions this workflow needs (for example
permission-issues, permission-pull-requests, permission-contents, etc. as
applicable). Update the step to include the minimal permission- inputs required
by subsequent steps so the generated token has least-privilege access.
In @.github/workflows/bot-autoassign-pr-issue-link.yml:
- Around line 20-25: The GitHub App token step (id: generate-token, uses:
actions/create-github-app-token@v2) is too broad; add permission-* inputs under
the with: block to downscope the token — for this workflow add at minimum
permission-issues: write and permission-pull-requests: read (or adjust to write
if the job needs to modify PRs) so the generated token only has the smallest
required permissions.
In @.github/workflows/bot-autoassign-stale-pr.yml:
- Around line 21-26: The GitHub App token step (id generate-token using
actions/create-github-app-token@v2) is currently created with installation-wide
permissions; scope it to the minimum required by adding explicit permission-*
inputs to the step (e.g., permission-issues, permission-pull-requests,
permission-repositories, etc.) that match only the permissions this workflow
needs. Modify the generate-token step to include those permission-<name>:
<access> inputs so the produced app token is limited to least privilege instead
of inheriting all installation permissions.
---
Duplicate comments:
In @.github/workflows/bot-autoassign-issue.yml:
- Around line 16-18: The workflow job respond-to-assign-request currently runs
for every issue comment because its if only checks that the event is an issue
(github.event.issue.pull_request == null); update the job's if to also prefilter
the comment body so the job runs only when the comment likely requests
assignment (e.g., add a condition using github.event.comment.body and the
contains/matches operator to look for phrases like "assign me", "please assign",
or "assign @", e.g. github.event.comment.body matches '(?i)\\b(assign me|please
assign|assign @)\\b'); keep the existing PR-exclusion check and add this
additional predicate to the same if expression on the respond-to-assign-request
job so ordinary comments no-op locally instead of invoking the upstream bot.
In @.github/workflows/bot-autoassign-pr-issue-link.yml:
- Around line 4-5: The pull_request_target workflow currently includes
"reopened" in its types array, causing duplicate runs with
bot-autoassign-pr-reopen.yml; remove "reopened" from the types list in the
pull_request_target trigger (i.e., change types: [opened, reopened, closed] to
types: [opened, closed]) so only the dedicated reopen workflow handles reopen
events, and ensure no other logic in this workflow depends on reopen events.
In @.github/workflows/bot-autoassign-pr-reopen.yml:
- Around line 23-28: The GitHub App token created by the generate-token step
using actions/create-github-app-token@v2 is currently unscoped; add explicit
permission-* inputs to the generate-token steps (the step with id
"generate-token" that uses actions/create-github-app-token@v2) to restrict the
app token to only the least-privilege permissions needed by the workflow (e.g.,
permission-issues, permission-pull-requests, permission-actions as appropriate);
update both occurrences (the step at lines shown and the duplicate) to include
the corresponding permission-* keys and values so the created token does not
inherit all installation permissions.
- Around line 54-56: The handle-pr-activity job currently runs for every PR
comment and fails when PRActivityBot exits non‑zero; narrow the workflow
conditional (the if on the job named handle-pr-activity) so it only runs for
relevant comments — e.g., require the commenter to be the PR author by adding a
check comparing github.event.comment.user.login to
github.event.issue.user.login, or require specific trigger keywords by using
contains(github.event.comment.body, '<keyword>') (or combine both with ||), so
routine review comments don't start the job; alternatively, coordinate upstream
to make PRActivityBot return 0 on no-op cases.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 395d2800-2ebc-4ee4-9e62-18e982bd33d2
📒 Files selected for processing (4)
.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml
📜 Review details
⏰ 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). (9)
- GitHub Check: Python==3.12 | django~=5.1.0
- GitHub Check: Python==3.10 | django~=5.2.0
- GitHub Check: Python==3.12 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=5.1.0
- GitHub Check: Python==3.10 | django~=4.2.0
- GitHub Check: Python==3.13 | django~=5.1.0
- GitHub Check: Python==3.11 | django~=5.2.0
- GitHub Check: Python==3.12 | django~=4.2.0
- GitHub Check: Python==3.10 | django~=5.1.0
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:31.829Z
Learning: Repository: openwisp/openwisp-controller
File/Area: .github/workflows/backport.yml (backport-on-comment condition)
Learning: Project policy is to restrict the backport trigger via issue comments to users with author_association "MEMBER" or "OWNER" only; "COLLABORATOR" is intentionally excluded (per maintainer feedback on PR `#1233`).
📚 Learning: 2026-02-24T16:25:20.080Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:20.080Z
Learning: In .github/workflows/backport.yml, enforce that backport-on-comment triggers only for users with author_association MEMBE R or OWNER (COLLABORATOR excluded), reflecting maintainer feedback. Update the trigger condition to check author_association and restrict to MEMBERS/OWNERS; document rationale and PR `#1233` reference in code comments.
Applied to files:
.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-reopen.yml
📚 Learning: 2026-02-24T16:24:55.443Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:22-22
Timestamp: 2026-02-24T16:24:55.443Z
Learning: In repositories within the OpenWISP organization, it is acceptable to reference reusable workflows from other OpenWISP-controlled repos using mutable refs (e.g., master) in .github/workflows. This is permissible due to the shared trust boundary within the organization. If applying this pattern, ensure the target repos are under the same organization and maintain awareness of potential breakages from upstream mutable refs; consider pinning to a tagged version for longer-term stability when appropriate.
Applied to files:
.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-reopen.yml
📚 Learning: 2026-02-17T19:13:17.774Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: openwisp_controller/config/whois/commands.py:0-0
Timestamp: 2026-02-17T19:13:17.774Z
Learning: The openwisp-controller repository does not use Ruff as a linting tool. Do not suggest code changes based on Ruff warnings for this repository.
Applied to files:
.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-stale-pr.yml
📚 Learning: 2026-02-21T20:25:06.553Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: requirements.txt:20-20
Timestamp: 2026-02-21T20:25:06.553Z
Learning: The openwisp-controller project is moving away from the `~=` (compatible release) version specifier in requirements.txt because it generates too many Dependabot PRs. The preferred format is `>=X.Y.Z,<MAJOR+1.0.0` (e.g., `geoip2>=5.1.0,<6.0.0`). Do not suggest converting to `~=` format.
Applied to files:
.github/workflows/bot-autoassign-stale-pr.yml
🔇 Additional comments (5)
.github/workflows/bot-autoassign-pr-reopen.yml (1)
1-87: LGTM on workflow structure and organization.The workflow correctly separates PR reopen events from issue comment events into distinct jobs with appropriate conditions. Using
pull_request_target(instead ofpull_request) is appropriate for cross-repo checkout scenarios. Based on learnings, using mutable refs likemasterforopenwisp/openwisp-utilsis acceptable within the OpenWISP organization's shared trust boundary..github/workflows/bot-autoassign-stale-pr.yml (2)
13-15: Good choice:cancel-in-progress: falsefor scheduled jobs.This prevents a new scheduled run from canceling an in-progress run, ensuring daily stale PR management completes reliably.
43-49: LGTM on bot invocation.The
stale_prcommand correctly omits$GITHUB_EVENT_PATHsince scheduled runs don't have meaningful event payloads. The environment variables are appropriately set..github/workflows/bot-autoassign-pr-issue-link.yml (1)
27-49: LGTM on bot execution setup.The checkout, Python setup, dependency installation, and bot invocation follow the established pattern. Based on learnings, using mutable refs like
masterforopenwisp/openwisp-utilsis acceptable within the OpenWISP organization..github/workflows/bot-autoassign-issue.yml (1)
11-13: LGTM on concurrency configuration.The concurrency group keyed by repository and issue number with
cancel-in-progress: truecorrectly prevents redundant runs when multiple comments are posted rapidly on the same issue.
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (7)
.github/workflows/bot-autoassign-pr-issue-link.yml (2)
4-5:⚠️ Potential issue | 🟠 MajorLeave
reopenedto the dedicated reopen workflow.The upstream
issue_assignmentbot already handlespull_request_targetactionsopenedandreopened. Because.github/workflows/bot-autoassign-pr-reopen.ymlalso runs onreopenedand uses a different concurrency group, a reopen event can execute both workflows in parallel and duplicate assignment/comment side effects. Droppingreopenedhere avoids that overlap. (raw.githubusercontent.com)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-issue-link.yml around lines 4 - 5, The workflow currently triggers on pull_request_target with types [opened, reopened, closed], causing duplicate execution with the dedicated reopen workflow; update the pull_request_target trigger (the types array in this workflow) to remove "reopened" so it only lists "opened" and "closed" (i.e., change types: [opened, reopened, closed] to types: [opened, closed]) to avoid overlapping runs with the reopen workflow.
20-25:⚠️ Potential issue | 🟠 MajorScope this app token explicitly.
As written, the PR-linking workflow also mints an installation token without any
permission-*inputs, so it inherits the app installation’s full permission set. Please downscope it to the smallest set required by this bot path. (github.com)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-issue-link.yml around lines 20 - 25, The GitHub App token step "Generate GitHub App token" (id: generate-token, uses: actions/create-github-app-token@v2) is currently created without scoped permissions; update that step to include an explicit permissions map limiting the token to the minimal rights the bot needs (e.g., permissions: issues: write and pull_requests: write, plus any additional read-only rights if your linking requires them such as metadata or contents: read). Add the permissions input to the action invocation so the installation token is downscoped rather than inheriting the app installation’s full permission set..github/workflows/bot-autoassign-pr-reopen.yml (2)
23-28:⚠️ Potential issue | 🟠 MajorDownscope both GitHub App tokens.
Both
generate-tokensteps mint installation tokens without anypermission-*inputs, so they inherit the app installation’s full permission set instead of the minimum this workflow needs. Please explicitly request only the scopes required by the reopen/comment handlers. (github.com)Also applies to: 58-63
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-reopen.yml around lines 23 - 28, The generate-token steps currently mint installation tokens with full app permissions; update each create-github-app-token step (the ones with id "generate-token") to explicitly request only the minimal permissions needed for reopen/comment handlers by adding permission inputs (for example permission-issues: write and permission-pull-requests: write) under with:, and ensure both occurrences of the generate-token step in the workflow are changed to include those permission-* entries so the token is downscoped.
54-56:⚠️ Potential issue | 🟠 MajorDon’t invoke
pr_reopenon every PR comment.Line 56 matches every PR
issue_comment, but the current upstreampr_reopenentrypoint routesissue_commentevents toPRActivityBot, which returnsFalsefor normal no-op cases like “comment not from PR author” or “PR is not stale”;main()then maps thatFalseto exit code 1. In practice, ordinary review discussion will make this workflow fail unless you prefilter the comments or make upstream no-ops exit successfully. (github.com)Also applies to: 80-87
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-reopen.yml around lines 54 - 56, The workflow currently triggers handle-pr-activity for every issue_comment which causes pr_reopen (the pr_reopen entrypoint invoking PRActivityBot -> main()) to run and return exit code 1 on benign no-ops; narrow the trigger so pr_reopen only runs when a real reopen command or actionable comment happens — for example change the conditional for handle-pr-activity to require issue_comment.action in (created, edited) plus a prefilter for a command token in the comment body (e.g., "/reopen") or restrict to comments by the PR author, or alternatively add a wrapper check step that reads github.event.comment.body and only calls the pr_reopen action when the body matches the trigger; reference PRActivityBot and main() so the prefilter prevents upstream main() from being invoked for routine discussion..github/workflows/bot-autoassign-issue.yml (2)
16-18:⚠️ Potential issue | 🟠 MajorPrefilter assignment requests before running the bot.
Line 18 only excludes PR comments, so this job still runs on every ordinary issue discussion. The current upstream
issue_assignmentbot returnsFalsewhen the comment body does not match one of its assignment-request phrases, and itsmain()converts that to exit code 1, which will turn routine comments into failed workflow runs. Add a body-level guard here, or change upstream no-op handling to succeed. (raw.githubusercontent.com)Also applies to: 42-49
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-issue.yml around lines 16 - 18, The job respond-to-assign-request currently only excludes PRs and therefore runs on every issue comment; add a body-level guard to the job's if to prefilter assignment-request phrases so the workflow doesn't run (and fail) for ordinary comments — for example augment the if to: github.event.issue.pull_request == null && (contains(github.event.comment.body, 'please assign') || contains(github.event.comment.body, 'assign me') || contains(github.event.comment.body, '/assign')) to match the upstream issue_assignment_bot.py's expected phrases, or alternatively modify the upstream main() behavior to return a zero exit code when no-match occurs; update the workflow job condition (respond-to-assign-request) or the action's no-op handling accordingly.
20-25:⚠️ Potential issue | 🟠 MajorScope the app token to least privilege.
This token is still created without any explicit
permission-*inputs, so it inherits the installation’s full permission set. Please downscope it to only the permissions the issue-assignment path actually needs. (github.com)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-issue.yml around lines 20 - 25, The GitHub App token is being created without explicit permissions; update the step with id "generate-token" that uses "actions/create-github-app-token@v2" to include least-privilege permission inputs required for issue assignment (for example add inputs like "permission-issues: write" and "permission-metadata: read" or other minimal permission-* keys your assignment flow needs) so the token no longer inherits the installation’s full permission set..github/workflows/bot-autoassign-stale-pr.yml (1)
21-26:⚠️ Potential issue | 🟠 MajorDownscope the stale-PR app token.
The
generate-tokenstep still omitspermission-*inputs, which means the token inherits all permissions granted to the app installation. Please request only the minimal scopes needed for stale-label cleanup and issue reassignment. (github.com)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-stale-pr.yml around lines 21 - 26, The generate-token step (id: generate-token, uses: actions/create-github-app-token@v2) is currently creating a token with full installation permissions; add explicit permission inputs to downscope it. Update the step to include at minimum permission-issues: write (for stale-label cleanup and reassignment) and permission-pull-requests: write (if PR reassignment/labeling is required); include only the minimal permission-* keys needed and remove any broad defaults so the token only grants those specified scopes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/bot-autoassign-issue.yml:
- Around line 16-18: The job respond-to-assign-request currently only excludes
PRs and therefore runs on every issue comment; add a body-level guard to the
job's if to prefilter assignment-request phrases so the workflow doesn't run
(and fail) for ordinary comments — for example augment the if to:
github.event.issue.pull_request == null && (contains(github.event.comment.body,
'please assign') || contains(github.event.comment.body, 'assign me') ||
contains(github.event.comment.body, '/assign')) to match the upstream
issue_assignment_bot.py's expected phrases, or alternatively modify the upstream
main() behavior to return a zero exit code when no-match occurs; update the
workflow job condition (respond-to-assign-request) or the action's no-op
handling accordingly.
- Around line 20-25: The GitHub App token is being created without explicit
permissions; update the step with id "generate-token" that uses
"actions/create-github-app-token@v2" to include least-privilege permission
inputs required for issue assignment (for example add inputs like
"permission-issues: write" and "permission-metadata: read" or other minimal
permission-* keys your assignment flow needs) so the token no longer inherits
the installation’s full permission set.
In @.github/workflows/bot-autoassign-pr-issue-link.yml:
- Around line 4-5: The workflow currently triggers on pull_request_target with
types [opened, reopened, closed], causing duplicate execution with the dedicated
reopen workflow; update the pull_request_target trigger (the types array in this
workflow) to remove "reopened" so it only lists "opened" and "closed" (i.e.,
change types: [opened, reopened, closed] to types: [opened, closed]) to avoid
overlapping runs with the reopen workflow.
- Around line 20-25: The GitHub App token step "Generate GitHub App token" (id:
generate-token, uses: actions/create-github-app-token@v2) is currently created
without scoped permissions; update that step to include an explicit permissions
map limiting the token to the minimal rights the bot needs (e.g., permissions:
issues: write and pull_requests: write, plus any additional read-only rights if
your linking requires them such as metadata or contents: read). Add the
permissions input to the action invocation so the installation token is
downscoped rather than inheriting the app installation’s full permission set.
In @.github/workflows/bot-autoassign-pr-reopen.yml:
- Around line 23-28: The generate-token steps currently mint installation tokens
with full app permissions; update each create-github-app-token step (the ones
with id "generate-token") to explicitly request only the minimal permissions
needed for reopen/comment handlers by adding permission inputs (for example
permission-issues: write and permission-pull-requests: write) under with:, and
ensure both occurrences of the generate-token step in the workflow are changed
to include those permission-* entries so the token is downscoped.
- Around line 54-56: The workflow currently triggers handle-pr-activity for
every issue_comment which causes pr_reopen (the pr_reopen entrypoint invoking
PRActivityBot -> main()) to run and return exit code 1 on benign no-ops; narrow
the trigger so pr_reopen only runs when a real reopen command or actionable
comment happens — for example change the conditional for handle-pr-activity to
require issue_comment.action in (created, edited) plus a prefilter for a command
token in the comment body (e.g., "/reopen") or restrict to comments by the PR
author, or alternatively add a wrapper check step that reads
github.event.comment.body and only calls the pr_reopen action when the body
matches the trigger; reference PRActivityBot and main() so the prefilter
prevents upstream main() from being invoked for routine discussion.
In @.github/workflows/bot-autoassign-stale-pr.yml:
- Around line 21-26: The generate-token step (id: generate-token, uses:
actions/create-github-app-token@v2) is currently creating a token with full
installation permissions; add explicit permission inputs to downscope it. Update
the step to include at minimum permission-issues: write (for stale-label cleanup
and reassignment) and permission-pull-requests: write (if PR
reassignment/labeling is required); include only the minimal permission-* keys
needed and remove any broad defaults so the token only grants those specified
scopes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: ece8976c-cf68-4170-bb33-3e5a60a3da18
📒 Files selected for processing (4)
.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml
📜 Review details
⏰ 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). (11)
- GitHub Check: Python==3.12 | django~=5.2.0
- GitHub Check: Python==3.12 | django~=5.1.0
- GitHub Check: Python==3.13 | django~=5.2.0
- GitHub Check: Python==3.13 | django~=5.1.0
- GitHub Check: Python==3.10 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=5.2.0
- GitHub Check: Python==3.10 | django~=5.1.0
- GitHub Check: Python==3.11 | django~=4.2.0
- GitHub Check: Python==3.11 | django~=5.1.0
- GitHub Check: Python==3.12 | django~=4.2.0
- GitHub Check: Python==3.10 | django~=4.2.0
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:31.829Z
Learning: Repository: openwisp/openwisp-controller
File/Area: .github/workflows/backport.yml (backport-on-comment condition)
Learning: Project policy is to restrict the backport trigger via issue comments to users with author_association "MEMBER" or "OWNER" only; "COLLABORATOR" is intentionally excluded (per maintainer feedback on PR `#1233`).
📚 Learning: 2026-02-24T16:25:20.080Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:20.080Z
Learning: In .github/workflows/backport.yml, enforce that backport-on-comment triggers only for users with author_association MEMBE R or OWNER (COLLABORATOR excluded), reflecting maintainer feedback. Update the trigger condition to check author_association and restrict to MEMBERS/OWNERS; document rationale and PR `#1233` reference in code comments.
Applied to files:
.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-issue.yml
📚 Learning: 2026-02-24T16:24:55.443Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:22-22
Timestamp: 2026-02-24T16:24:55.443Z
Learning: In repositories within the OpenWISP organization, it is acceptable to reference reusable workflows from other OpenWISP-controlled repos using mutable refs (e.g., master) in .github/workflows. This is permissible due to the shared trust boundary within the organization. If applying this pattern, ensure the target repos are under the same organization and maintain awareness of potential breakages from upstream mutable refs; consider pinning to a tagged version for longer-term stability when appropriate.
Applied to files:
.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-issue.yml
📚 Learning: 2026-02-17T19:13:17.774Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: openwisp_controller/config/whois/commands.py:0-0
Timestamp: 2026-02-17T19:13:17.774Z
Learning: The openwisp-controller repository does not use Ruff as a linting tool. Do not suggest code changes based on Ruff warnings for this repository.
Applied to files:
.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-stale-pr.yml
📚 Learning: 2026-02-21T20:25:06.553Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: requirements.txt:20-20
Timestamp: 2026-02-21T20:25:06.553Z
Learning: The openwisp-controller project is moving away from the `~=` (compatible release) version specifier in requirements.txt because it generates too many Dependabot PRs. The preferred format is `>=X.Y.Z,<MAJOR+1.0.0` (e.g., `geoip2>=5.1.0,<6.0.0`). Do not suggest converting to `~=` format.
Applied to files:
.github/workflows/bot-autoassign-stale-pr.yml
Eeshu-Yadav
changed the title
Author
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
1 similar comment
Contributor
✅ Actions performedReview triggered.
|
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (3)
.github/workflows/bot-autoassign-issue.yml (1)
13-16:⚠️ Potential issue | 🟠 MajorPrefilter assignment-intent comments before invoking
issue_assignment.Line 13 currently runs for every non-PR issue comment. Add a comment-body prefilter (or guarantee upstream no-op exits with success) to avoid noisy/failing runs on normal discussion.
🔧 Example guard (adjust phrase list to upstream bot triggers)
- if: github.event.issue.pull_request == null + if: github.event.issue.pull_request == null && contains(toLower(github.event.comment.body), 'assign')In openwisp/openwisp-utils (current master), for bot_command `issue_assignment`, which comment patterns are treated as assignment requests, and what exit code is returned for non-matching comments?🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-issue.yml around lines 13 - 16, The workflow currently triggers the reusable job for every non-PR issue comment (if: github.event.issue.pull_request == null) which causes noisy/failing runs; add a prefilter that checks github.event.comment.body for the bot trigger phrases before calling the reusable workflow (or run a short step that matches comment text against assigned trigger patterns and exits 0 for non-matches), referencing the existing condition and the with: bot_command: issue_assignment invocation so only comments matching the assignment-intent patterns invoke the reusable job..github/workflows/bot-autoassign-pr-reopen.yml (1)
24-24:⚠️ Potential issue | 🟠 MajorNarrow
handle-pr-activitytrigger to stale PR activity (or explicit command) to avoid noisy no-op runs.At Line 24, any PR-author comment triggers the reusable bot. If
pr_reopentreats non-stale/no-op comments as failure, routine discussion will turn runs red.🔧 Minimal guard
- if: github.event_name == 'issue_comment' && github.event.issue.pull_request && github.event.issue.user.login == github.event.comment.user.login + if: github.event_name == 'issue_comment' && github.event.issue.pull_request && github.event.issue.user.login == github.event.comment.user.login && contains(join(github.event.issue.labels.*.name, ','), 'stale')In openwisp/openwisp-utils (current master), for bot_command `pr_reopen`, what exit code is returned on `issue_comment` events when the PR is not labeled `stale`?🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-reopen.yml at line 24, The current workflow root if-condition triggers on any PR-author comment; change it to only run when the PR is labeled "stale" or the comment explicitly invokes the bot (e.g., contains the pr_reopen command). Update the if expression that currently reads github.event_name == 'issue_comment' && github.event.issue.pull_request && github.event.issue.user.login == github.event.comment.user.login to also check (contains(github.event.comment.body, '/pr_reopen') || contains(join(github.event.issue.labels.*.name, ','), 'stale')), so the reusable job only runs for explicit /pr_reopen commands or when the PR has a "stale" label..github/workflows/bot-autoassign-pr-issue-link.yml (1)
4-4:⚠️ Potential issue | 🟠 MajorRemove
reopenedfrom this workflow trigger to avoid duplicate reopen handling.Line 4 overlaps with
.github/workflows/bot-autoassign-pr-reopen.yml(alsoreopened), so both workflows can run for the same reopen event with different concurrency groups.✂️ Minimal fix
- types: [opened, reopened, closed] + types: [opened, closed]In openwisp/openwisp-utils (current master), does bot_command `issue_assignment` actively process `pull_request_target` action `reopened` (assign/unassign linked issues), and does that overlap with bot_command `pr_reopen` behavior?🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-issue-link.yml at line 4, Remove the "reopened" event from the types list in bot-autoassign-pr-issue-link.yml (the line currently reads types: [opened, reopened, closed]) to prevent duplicate handling with the pr-reopen workflow; update the array to exclude "reopened" (e.g., types: [opened, closed]) so only one workflow (bot-autoassign-pr-reopen.yml) handles reopen events.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/bot-autoassign-issue.yml:
- Around line 13-16: The workflow currently triggers the reusable job for every
non-PR issue comment (if: github.event.issue.pull_request == null) which causes
noisy/failing runs; add a prefilter that checks github.event.comment.body for
the bot trigger phrases before calling the reusable workflow (or run a short
step that matches comment text against assigned trigger patterns and exits 0 for
non-matches), referencing the existing condition and the with: bot_command:
issue_assignment invocation so only comments matching the assignment-intent
patterns invoke the reusable job.
In @.github/workflows/bot-autoassign-pr-issue-link.yml:
- Line 4: Remove the "reopened" event from the types list in
bot-autoassign-pr-issue-link.yml (the line currently reads types: [opened,
reopened, closed]) to prevent duplicate handling with the pr-reopen workflow;
update the array to exclude "reopened" (e.g., types: [opened, closed]) so only
one workflow (bot-autoassign-pr-reopen.yml) handles reopen events.
In @.github/workflows/bot-autoassign-pr-reopen.yml:
- Line 24: The current workflow root if-condition triggers on any PR-author
comment; change it to only run when the PR is labeled "stale" or the comment
explicitly invokes the bot (e.g., contains the pr_reopen command). Update the if
expression that currently reads github.event_name == 'issue_comment' &&
github.event.issue.pull_request && github.event.issue.user.login ==
github.event.comment.user.login to also check
(contains(github.event.comment.body, '/pr_reopen') ||
contains(join(github.event.issue.labels.*.name, ','), 'stale')), so the reusable
job only runs for explicit /pr_reopen commands or when the PR has a "stale"
label.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3f6b872b-38ed-4b4f-8b93-72ca0646a1db
📒 Files selected for processing (4)
.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml
📜 Review details
⏰ 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). (11)
- GitHub Check: Python==3.12 | django~=5.2.0
- GitHub Check: Python==3.12 | django~=4.2.0
- GitHub Check: Python==3.13 | django~=5.1.0
- GitHub Check: Python==3.12 | django~=5.1.0
- GitHub Check: Python==3.13 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=4.2.0
- GitHub Check: Python==3.11 | django~=5.2.0
- GitHub Check: Python==3.10 | django~=5.1.0
- GitHub Check: Python==3.10 | django~=4.2.0
- GitHub Check: Python==3.10 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=5.1.0
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:31.829Z
Learning: Repository: openwisp/openwisp-controller
File/Area: .github/workflows/backport.yml (backport-on-comment condition)
Learning: Project policy is to restrict the backport trigger via issue comments to users with author_association "MEMBER" or "OWNER" only; "COLLABORATOR" is intentionally excluded (per maintainer feedback on PR `#1233`).
📚 Learning: 2026-02-24T16:25:20.080Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:20.080Z
Learning: In .github/workflows/backport.yml, enforce that backport-on-comment triggers only for users with author_association MEMBE R or OWNER (COLLABORATOR excluded), reflecting maintainer feedback. Update the trigger condition to check author_association and restrict to MEMBERS/OWNERS; document rationale and PR `#1233` reference in code comments.
Applied to files:
.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-issue.yml
📚 Learning: 2026-02-24T16:24:55.443Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:22-22
Timestamp: 2026-02-24T16:24:55.443Z
Learning: In repositories within the OpenWISP organization, it is acceptable to reference reusable workflows from other OpenWISP-controlled repos using mutable refs (e.g., master) in .github/workflows. This is permissible due to the shared trust boundary within the organization. If applying this pattern, ensure the target repos are under the same organization and maintain awareness of potential breakages from upstream mutable refs; consider pinning to a tagged version for longer-term stability when appropriate.
Applied to files:
.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-issue.yml
📚 Learning: 2026-02-17T19:13:17.774Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: openwisp_controller/config/whois/commands.py:0-0
Timestamp: 2026-02-17T19:13:17.774Z
Learning: The openwisp-controller repository does not use Ruff as a linting tool. Do not suggest code changes based on Ruff warnings for this repository.
Applied to files:
.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-pr-issue-link.yml
📚 Learning: 2026-02-21T20:25:06.553Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: requirements.txt:20-20
Timestamp: 2026-02-21T20:25:06.553Z
Learning: The openwisp-controller project is moving away from the `~=` (compatible release) version specifier in requirements.txt because it generates too many Dependabot PRs. The preferred format is `>=X.Y.Z,<MAJOR+1.0.0` (e.g., `geoip2>=5.1.0,<6.0.0`). Do not suggest converting to `~=` format.
Applied to files:
.github/workflows/bot-autoassign-stale-pr.yml
🔇 Additional comments (1)
.github/workflows/bot-autoassign-stale-pr.yml (1)
1-20: Looks good — stale PR workflow wiring is consistent with the reusable bot pattern.Triggers, permissions, concurrency, and secrets wiring are coherent for
bot_command: stale_pr.
Eeshu-Yadav
force-pushed
the
feature/bot-autoassign
branch
from
6dace8b to
b3adfc3
Compare
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (2)
.github/workflows/bot-autoassign-pr-reopen.yml (1)
24-24:⚠️ Potential issue | 🟠 MajorLimit
handle-pr-activityto stale-labeled PR comments.At Line 24, this runs on any PR-author comment. The upstream activity bot can return non-zero when the PR is not stale, causing avoidable failed runs on routine comments.
🔧 Suggested fix
handle-pr-activity: - if: github.event_name == 'issue_comment' && github.event.issue.pull_request && github.event.issue.user.login == github.event.comment.user.login + if: > + github.event_name == 'issue_comment' && + github.event.issue.pull_request && + github.event.issue.user.login == github.event.comment.user.login && + contains(join(github.event.issue.labels.*.name, ','), 'stale')#!/bin/bash set -euo pipefail pr_bot_url="https://raw.githubusercontent.com/openwisp/openwisp-utils/master/.github/actions/bot-autoassign/pr_reopen_bot.py" echo "Checking PR activity no-op behavior ..." curl -sL "$pr_bot_url" | rg -n "PR is not stale, skipping|Comment not from PR author, skipping|return False|return 0 if result else 1"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-reopen.yml at line 24, The workflow currently triggers handle-pr-activity for any PR-author comment; change the if condition to also require the PR to have the stale label so the job only runs for stale-labeled PRs. Update the conditional on the job that currently uses "if: github.event_name == 'issue_comment' && github.event.issue.pull_request && github.event.issue.user.login == github.event.comment.user.login" to include a labels check (e.g., add "&& contains(github.event.issue.labels.*.name, 'stale')" or equivalent expression) so the job only runs when the PR has the "stale" label..github/workflows/bot-autoassign-issue.yml (1)
13-13:⚠️ Potential issue | 🟠 MajorGuard this job to assignment-request comments only.
At Line 13, this runs for every non-PR issue comment. The upstream
issue_assignmentbot can return non-zero for ordinary comments, which turns routine discussion into failed workflow runs.🔧 Suggested fix
jobs: respond-to-assign-request: - if: github.event.issue.pull_request == null + if: > + github.event.issue.pull_request == null && + ( + contains(github.event.comment.body, 'assign me') || + contains(github.event.comment.body, 'assign this issue to me') || + contains(github.event.comment.body, 'can i work on this') || + contains(github.event.comment.body, 'i would like to work on this') || + contains(github.event.comment.body, 'i want to work on this') || + contains(github.event.comment.body, 'please assign this to me') || + contains(github.event.comment.body, 'can you assign this to me') + )#!/bin/bash set -euo pipefail issue_bot_url="https://raw.githubusercontent.com/openwisp/openwisp-utils/master/.github/actions/bot-autoassign/issue_assignment_bot.py" entry_url="https://raw.githubusercontent.com/openwisp/openwisp-utils/master/.github/actions/bot-autoassign/__main__.py" echo "Checking no-op handling in issue_assignment_bot.py ..." curl -sL "$issue_bot_url" | rg -n "Comment does not contain assignment request|return False|return 0 if result else 1" echo "Checking dispatcher path in __main__.py ..." curl -sL "$entry_url" | rg -n "issue_assignment|return issue_main\\(|sys.exit\\(main\\)"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-issue.yml at line 13, The current job guard (the expression "github.event.issue.pull_request == null") runs for every non-PR issue comment; change the job condition so it only triggers for newly created issue comments that contain the assignment-request trigger the upstream bot expects (i.e., restrict to issue_comment created events and require the comment body matches the assignment-request keyword/regex the issue_assignment bot uses). Update the condition in the workflow where "github.event.issue.pull_request == null" is used to also check github.event.action is "created" and that github.event.comment.body contains the assignment-request trigger so ordinary discussion comments do not run the bot.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/bot-autoassign-issue.yml:
- Line 13: The current job guard (the expression
"github.event.issue.pull_request == null") runs for every non-PR issue comment;
change the job condition so it only triggers for newly created issue comments
that contain the assignment-request trigger the upstream bot expects (i.e.,
restrict to issue_comment created events and require the comment body matches
the assignment-request keyword/regex the issue_assignment bot uses). Update the
condition in the workflow where "github.event.issue.pull_request == null" is
used to also check github.event.action is "created" and that
github.event.comment.body contains the assignment-request trigger so ordinary
discussion comments do not run the bot.
In @.github/workflows/bot-autoassign-pr-reopen.yml:
- Line 24: The workflow currently triggers handle-pr-activity for any PR-author
comment; change the if condition to also require the PR to have the stale label
so the job only runs for stale-labeled PRs. Update the conditional on the job
that currently uses "if: github.event_name == 'issue_comment' &&
github.event.issue.pull_request && github.event.issue.user.login ==
github.event.comment.user.login" to include a labels check (e.g., add "&&
contains(github.event.issue.labels.*.name, 'stale')" or equivalent expression)
so the job only runs when the PR has the "stale" label.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3babe1a8-77d0-4ecd-9f97-9501e27fb70d
📒 Files selected for processing (4)
.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml
📜 Review details
⏰ 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). (11)
- GitHub Check: Python==3.12 | django~=5.2.0
- GitHub Check: Python==3.12 | django~=4.2.0
- GitHub Check: Python==3.13 | django~=5.1.0
- GitHub Check: Python==3.12 | django~=5.1.0
- GitHub Check: Python==3.13 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=4.2.0
- GitHub Check: Python==3.11 | django~=5.2.0
- GitHub Check: Python==3.10 | django~=5.1.0
- GitHub Check: Python==3.10 | django~=4.2.0
- GitHub Check: Python==3.10 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=5.1.0
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:31.829Z
Learning: Repository: openwisp/openwisp-controller
File/Area: .github/workflows/backport.yml (backport-on-comment condition)
Learning: Project policy is to restrict the backport trigger via issue comments to users with author_association "MEMBER" or "OWNER" only; "COLLABORATOR" is intentionally excluded (per maintainer feedback on PR `#1233`).
📚 Learning: 2026-02-24T16:25:20.080Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:20.080Z
Learning: In .github/workflows/backport.yml, enforce that backport-on-comment triggers only for users with author_association MEMBE R or OWNER (COLLABORATOR excluded), reflecting maintainer feedback. Update the trigger condition to check author_association and restrict to MEMBERS/OWNERS; document rationale and PR `#1233` reference in code comments.
Applied to files:
.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml
📚 Learning: 2026-02-24T16:24:55.443Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:22-22
Timestamp: 2026-02-24T16:24:55.443Z
Learning: In repositories within the OpenWISP organization, it is acceptable to reference reusable workflows from other OpenWISP-controlled repos using mutable refs (e.g., master) in .github/workflows. This is permissible due to the shared trust boundary within the organization. If applying this pattern, ensure the target repos are under the same organization and maintain awareness of potential breakages from upstream mutable refs; consider pinning to a tagged version for longer-term stability when appropriate.
Applied to files:
.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml
📚 Learning: 2026-02-17T19:13:17.774Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: openwisp_controller/config/whois/commands.py:0-0
Timestamp: 2026-02-17T19:13:17.774Z
Learning: The openwisp-controller repository does not use Ruff as a linting tool. Do not suggest code changes based on Ruff warnings for this repository.
Applied to files:
.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-stale-pr.yml
📚 Learning: 2026-02-21T20:25:06.553Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: requirements.txt:20-20
Timestamp: 2026-02-21T20:25:06.553Z
Learning: The openwisp-controller project is moving away from the `~=` (compatible release) version specifier in requirements.txt because it generates too many Dependabot PRs. The preferred format is `>=X.Y.Z,<MAJOR+1.0.0` (e.g., `geoip2>=5.1.0,<6.0.0`). Do not suggest converting to `~=` format.
Applied to files:
.github/workflows/bot-autoassign-stale-pr.yml
🔇 Additional comments (2)
.github/workflows/bot-autoassign-stale-pr.yml (1)
1-20: Looks good for stale PR automation wiring.Triggers, permissions, concurrency, and reusable workflow invocation are consistent with the stated objective.
.github/workflows/bot-autoassign-pr-issue-link.yml (1)
14-14: Close-event guard is well defined.The condition at Line 14 correctly prevents execution on merged PR closes while preserving opened/reopened and unmerged-close handling.
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/bot-autoassign-pr-issue-link.yml (1)
3-4:⚠️ Potential issue | 🟠 MajorRemove
reopenedhere to prevent duplicate reopen handling.Line 4 overlaps with
.github/workflows/bot-autoassign-pr-reopen.yml(Lines 3-4), so both workflows run on the same reopen event with different concurrency groups. This can cause redundant assignment/comment actions.✂️ Minimal fix
on: pull_request_target: - types: [opened, reopened, closed] + types: [opened, closed]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/bot-autoassign-pr-issue-link.yml around lines 3 - 4, The pull_request_target trigger currently lists types: [opened, reopened, closed] which duplicates reopen handling with the other workflow; remove the "reopened" entry from the types array under the pull_request_target block (i.e., change pull_request_target: types to only include opened and closed) so reopen events are handled solely by the bot-autoassign-pr-reopen workflow.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/bot-autoassign-pr-issue-link.yml:
- Around line 3-4: The pull_request_target trigger currently lists types:
[opened, reopened, closed] which duplicates reopen handling with the other
workflow; remove the "reopened" entry from the types array under the
pull_request_target block (i.e., change pull_request_target: types to only
include opened and closed) so reopen events are handled solely by the
bot-autoassign-pr-reopen workflow.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0351b430-1f3c-44bd-8168-9d5ff844d7dd
📒 Files selected for processing (4)
.github/workflows/bot-autoassign-issue.yml.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml
📜 Review details
🧰 Additional context used
🧠 Learnings (5)
📓 Common learnings
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:31.829Z
Learning: Repository: openwisp/openwisp-controller
File/Area: .github/workflows/backport.yml (backport-on-comment condition)
Learning: Project policy is to restrict the backport trigger via issue comments to users with author_association "MEMBER" or "OWNER" only; "COLLABORATOR" is intentionally excluded (per maintainer feedback on PR `#1233`).
📚 Learning: 2026-02-24T16:25:20.080Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:35-35
Timestamp: 2026-02-24T16:25:20.080Z
Learning: In .github/workflows/backport.yml, enforce that backport-on-comment triggers only for users with author_association MEMBE R or OWNER (COLLABORATOR excluded), reflecting maintainer feedback. Update the trigger condition to check author_association and restrict to MEMBERS/OWNERS; document rationale and PR `#1233` reference in code comments.
Applied to files:
.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-issue.yml
📚 Learning: 2026-02-24T16:24:55.443Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1233
File: .github/workflows/backport.yml:22-22
Timestamp: 2026-02-24T16:24:55.443Z
Learning: In repositories within the OpenWISP organization, it is acceptable to reference reusable workflows from other OpenWISP-controlled repos using mutable refs (e.g., master) in .github/workflows. This is permissible due to the shared trust boundary within the organization. If applying this pattern, ensure the target repos are under the same organization and maintain awareness of potential breakages from upstream mutable refs; consider pinning to a tagged version for longer-term stability when appropriate.
Applied to files:
.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-pr-reopen.yml.github/workflows/bot-autoassign-stale-pr.yml.github/workflows/bot-autoassign-issue.yml
📚 Learning: 2026-02-17T19:13:17.774Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: openwisp_controller/config/whois/commands.py:0-0
Timestamp: 2026-02-17T19:13:17.774Z
Learning: The openwisp-controller repository does not use Ruff as a linting tool. Do not suggest code changes based on Ruff warnings for this repository.
Applied to files:
.github/workflows/bot-autoassign-pr-issue-link.yml.github/workflows/bot-autoassign-stale-pr.yml
📚 Learning: 2026-02-21T20:25:06.553Z
Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: requirements.txt:20-20
Timestamp: 2026-02-21T20:25:06.553Z
Learning: The openwisp-controller project is moving away from the `~=` (compatible release) version specifier in requirements.txt because it generates too many Dependabot PRs. The preferred format is `>=X.Y.Z,<MAJOR+1.0.0` (e.g., `geoip2>=5.1.0,<6.0.0`). Do not suggest converting to `~=` format.
Applied to files:
.github/workflows/bot-autoassign-stale-pr.yml
🔇 Additional comments (3)
.github/workflows/bot-autoassign-issue.yml (1)
1-19: Looks good for issue-comment routing and delegation.The event scope and Line 13 guard correctly avoid PR comments before invoking the reusable bot workflow.
.github/workflows/bot-autoassign-stale-pr.yml (1)
1-20: Stale PR workflow wiring is clean.Triggers, permissions, concurrency, and bot command forwarding are consistent with the intended stale-management flow.
.github/workflows/bot-autoassign-pr-reopen.yml (1)
15-30: Reopen flow split is well-structured.The separate jobs for explicit reopen events and PR-author activity are clearly gated and correctly routed to the shared
pr_reopenbot command.
Eeshu-Yadav
force-pushed
the
feature/bot-autoassign
branch
2 times, most recently
from
886d496 to
868d928
Compare
CI Failure AnalysisHello @Eeshu-Yadav, There is one Test Failure in your CI job. Failures & Remediation
|
Added GitHub Actions workflows to auto-assign issues, manage PR-issue linking, handle PR reopening reassignment, and manage stale PRs. Closes openwisp#1265
Refines the caller workflows to use the updated `reusable-bot-autoassign.yml` from openwisp-utils. Reduces boilerplate, removes custom installations, and fixes bugs like the bot running on merged PRs.
Removes 'reopened' from the types on `bot-autoassign-pr-issue-link.yml`. The `bot-autoassign-pr-reopen.yml` already properly handles PR reopens, meaning this additional trigger was causing bot spam and race conditions.
Eeshu-Yadav
force-pushed
the
feature/bot-autoassign
branch
from
868d928 to
9888f7d
Compare
[
{"line": 2026, "message": "AssertionError: 401 != 400"}
]Test Failure:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds the GitHub Actions workflows to auto-assign issues, manage PR-issue linking, handle PR reopening reassignment, and manage stale PRs.
These workflows check out
openwisp/openwisp-utilsto run the bot Python scripts, ensuring uniform behavior across all repositories.Related to the auto-assignment issue bot implementation.
closes #1265