Automated issue triage workflow

[moonbox3]

Motivation and Context

GitHub workflow to automate initial bug reports from issues.

Description

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the Contribution Guidelines
• All unit tests pass, and I have added new tests where possible
• Is this a breaking change? If yes, add "[BREAKING]" prefix to the title of the PR.

[Copilot]

Pull request overview

Adds a new GitHub Actions workflow to automatically triage newly opened issues (and allow manual invocation) by checking reporter team membership and then running DevFlow-based classification/repro steps.

Changes:

• Introduces .github/workflows/issue-triage.yml to run on issues: opened and workflow_dispatch.
• Adds a team-membership gate to skip auto-triage for internal reporters.
• Runs DevFlow scripts to classify spam/relevance and optionally trigger reproduction.

[moonbox3]

Automated Code Review

Reviewers: 4 | Confidence: 83%

✓ Correctness

The workflow is structurally sound for normal operation. The three issues from the prior review thread (secret exposure on any opened issue, concurrency group missing workflow_dispatch input, and catch-all error handling in team membership) remain unresolved in the current diff and are the most significant concerns. One new minor finding: the issue-author lookup via the REST API on line 75 does not guard against a null user field (which GitHub returns for deleted accounts), unlike line 68 which uses optional chaining.

✓ Security Reliability

The three main security concerns (unrestricted trigger on issues: opened, concurrency group missing inputs.issue_number, and fail-open on team membership API errors) were already identified in the existing unresolved review thread. Beyond those, the workflow follows good practices: issue number input is regex-validated (line 51), secrets are passed through environment variables rather than expression interpolation (avoiding script injection), and checkouts use persist-credentials: false. No new high-confidence security or reliability issues were found.

✓ Test Coverage

This PR adds a new GitHub Actions workflow for issue triage. From a test coverage perspective, the workflow embeds non-trivial team-membership-check logic as inline JavaScript (lines 67–96) rather than extracting it into a testable script under .github/scripts/, which is the established pattern in this repo (see stale_issue_pr_ping.py with its corresponding test_stale_issue_pr_ping.py). The inline JS includes fallback author resolution, API error handling, and membership state checking — all paths that would benefit from unit tests but currently cannot be tested. The core triage scripts (classify_issue_spam.py, trigger_issue_repro.py) live in an external private repo and are outside the scope of this PR. No blocking test-coverage issues, but the untested inline logic is a notable gap given existing repo conventions.

✓ Design Approach

The workflow is structurally sound: minimal permissions, input validation, credential hygiene (persist-credentials: false), and a two-job gate that skips triage for team members. The three issues raised in the prior review thread (trigger scope allowing any external issue to burn secrets, concurrency group not covering workflow_dispatch inputs, and fail-open error handling in team membership) remain unresolved in this diff and are the most significant design concerns. Beyond those, no new blocking design-approach issues were identified.

Suggestions

• Line 75: issue.user.login will throw a TypeError for issues opened by deleted GitHub accounts (user is null). Use optional chaining (issue.user?.login) or a null guard, consistent with line 68's context.payload.issue?.user?.login.
• Extract the inline JavaScript team-membership-check logic (lines 67–96) into a dedicated script under .github/scripts/ (e.g., check_team_membership.js) with unit tests under .github/tests/, following the established stale_issue_pr_ping.py / test_stale_issue_pr_ping.py pattern. This would allow testing the fallback author-resolution, active-membership distinction, and error-handling branches.
• The 'Stop after spam gate' step (line 155) is a misleading no-op—it logs but doesn't halt execution. The real gating relies on per-step if conditions, so any future step added without its own guard will silently bypass the spam gate. Consider failing the job when spam is detected (labeling is already applied) or restructuring into a separate job so the decision is enforced at the job-dependency level.

---

Automated review by moonbox3's agents

[github-actions]

Automated Code Review

Reviewers: 4 | Confidence: 87%

✓ Correctness

This workflow closely mirrors the existing devflow-pr-review.yml and follows established repo patterns. The prior review comments (concurrency group missing inputs.issue_number, null-safety on issue.user.login, overly permissive error catch in team check, and the no-op spam gate step) remain the significant correctness concerns. No additional blocking issues were found beyond what has already been flagged.

✓ Security Reliability

The workflow is well-structured and follows existing repository patterns (closely mirrors devflow-pr-review.yml). The most significant security and reliability concerns—fail-open error handling in team membership checks, null-safety on issue.user, concurrency group gaps for workflow_dispatch, and the non-blocking spam gate—have already been identified in the existing review thread. Input validation is solid (regex check on issue_number, all shell variables properly quoted, persist-credentials: false on checkouts). After thorough review, no new high-severity security or reliability issues were found beyond those already flaged.

✓ Test Coverage

This workflow adds non-trivial logic in two untested inline blocks: a bash script that resolves issue metadata with input validation (lines 38–59) and a JavaScript block that resolves the issue author and checks team membership (lines 67–96). The JS block's test gap is already identified in the existing review thread (moonbox3, line 96). However, the bash block's input-validation regex and event-type branching are also testable and currently uncovered. The repo's established convention (.github/scripts/ + .github/tests/, as demonstrated by stale_issue_pr_ping.py) provides a clear pattern for extracting and testing this logic. No new tests are included in this PR.

✓ Design Approach

I did a bounded context pass across the new workflow plus the adjacent automation it builds on (.github/workflows/devflow-pr-review.yml, .github/workflows/label-issues.yml, .github/workflows/stale-issue-pr-ping.yml, and the existing stale-issue script/tests). I did not find any additional design-approach problems beyond the concerns already captured in the unresolved review threads; the remaining issues I considered were either already raised there or would have required guessing about behavior in the private DevFlow scripts.

Suggestions

• The bash input-validation and event-routing logic in the 'Resolve issue metadata' step (lines 44–57) contains branching and a regex guard that would benefit from test coverage — consider extracting it into a testable script following the .github/scripts/ + .github/tests/ pattern already established by stale_issue_pr_ping.py.

---

Automated review by moonbox3's agents