feat(labels): estate label tooling + auto-triage for new issues - #79
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (32)
🧰 Additional context used🪛 zizmor (1.29.0).github/workflows/label-triage.yml[error] 43-43: overly broad permissions (excessive-permissions): issues: write is overly broad at the workflow level (excessive-permissions) [warning] 43-43: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment (undocumented-permissions) [info] 47-47: workflow or action definition without a name (anonymous-definition): this job (anonymous-definition) [warning] 33-40: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting (concurrency-limits) .github/workflows/labels.yml[error] 29-29: overly broad permissions (excessive-permissions): issues: write is overly broad at the workflow level (excessive-permissions) [warning] 29-29: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment (undocumented-permissions) [info] 33-33: workflow or action definition without a name (anonymous-definition): this job (anonymous-definition) [warning] 20-26: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting (concurrency-limits) 📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds a generated label catalogue, classifier rules, a jq-based issue classifier, an issue triage workflow, and a workflow that synchronises repository labels. ChangesLabel automation
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: ⚪ Minimal · up to This additive label tooling change has no identified current correctness, security, availability, or deployment issue; no actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant IssueEvent
participant label-triage.yml
participant classify-issue.jq
participant GitHubIssuesAPI
IssueEvent->>label-triage.yml: trigger issue classification
label-triage.yml->>GitHubIssuesAPI: fetch issue title and existing labels
label-triage.yml->>classify-issue.jq: provide classifier rules and issue data
classify-issue.jq->>label-triage.yml: return canonical label suggestions
label-triage.yml->>GitHubIssuesAPI: apply accepted labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (5 skipped: 5 unsupported.) 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 |
![codacy-production[bot]](https://avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull Request Overview
The PR introduces a zero-dependency label management and triage system. While Codacy results indicate the code is up to standards, the review identified several technical risks and policy discrepancies that should be addressed before merging.
The core issue classification engine in .github/scripts/classify-issue.jq is considered high-risk due to its complexity and the lack of local automated tests. This script uses sophisticated regex patterns that are prone to regression without a dedicated test suite. Furthermore, the triage workflow contains a medium-severity bug related to shell word splitting that could cause the system to fail when processing labels with spaces. Finally, there is a contradiction between the PR's stated ban on Python and internal comments referencing Python-based parity tests, which requires clarification for governance compliance.
About this PR
- The issue classification logic lacks accompanying automated tests within this PR. Given the potential for false positives in regex-based triage, a local test suite is recommended to prevent regressions.
- The internal documentation in
classify-issue.jqreferences a Python-based parity test (tests/test-classifier-parity.py). This contradicts the stated PR intent and estate-wide policy banning Python. If local testing is required, it should be implemented using permitted tools (e.g., shell/jq).
Test suggestions
- Classification of issue titles using conventional commit prefixes (e.g., 'feat:', 'fix:')
- Classification of issue titles using bracket tags (e.g., '[security]', '[estate]')
- Verification that the classifier does not add a 'type' label if one is already present on the issue
- Label sync workflow creates new labels defined in the canonical labels.json
- Label sync workflow updates color and description for existing labels not in the 'frozen' list
- Label sync workflow skips modifications for any label listed in the 'frozen' array
- Create a local shell/jq test suite for .github/scripts/classify-issue.jq
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Classification of issue titles using conventional commit prefixes (e.g., 'feat:', 'fix:')
2. Classification of issue titles using bracket tags (e.g., '[security]', '[estate]')
3. Verification that the classifier does not add a 'type' label if one is already present on the issue
4. Label sync workflow creates new labels defined in the canonical labels.json
5. Label sync workflow updates color and description for existing labels not in the 'frozen' list
6. Label sync workflow skips modifications for any label listed in the 'frozen' array
7. Create a local shell/jq test suite for .github/scripts/classify-issue.jq
TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback
| printf 'applying: %s\n' "${apply[*]}" | ||
| gh issue edit "$NUM" -R "$GITHUB_REPOSITORY" \ | ||
| $(printf -- '--add-label %q ' "${apply[@]}") \ | ||
| || echo "label apply failed - not failing the run" |
There was a problem hiding this comment.
🟡 MEDIUM RISK
The command substitution will undergo word splitting, which breaks label names containing spaces (e.g., 'good first issue'). Use a Bash array to safely collect and pass the arguments to gh issue edit.
| # (`port` + `ion` = "portion", and `port` is a live keyword). They are enabled | ||
| # only for shapes that are unambiguously truncated stems -- `-at` | ||
| # (instantiat, investigat, adjudicat) and `-ment` (document, implement). | ||
| def kwrx($kw): |
There was a problem hiding this comment.
🟡 MEDIUM RISK
Suggestion: The classification logic is sophisticated, particularly the kwrx function. Since parity tests are external, there is a risk of regressions. Recommendation: Create a local test suite (shell script) using jq to run the classifier against mock titles like 'clean up' and 'automation'.
| for f in "${FROZEN[@]}"; do [ "$f" = "$name" ] && frozen=1 && break; done | ||
| if [ "$frozen" -eq 1 ]; then skipped=$((skipped+1)); continue; fi | ||
|
|
||
| cur=$(printf '%s\n' "$existing" | awk -F'\t' -v n="$name" '$1==n{print;exit}') |
There was a problem hiding this comment.
⚪ LOW RISK
Suggestion: Searching through existing labels using an awk process inside a loop is inefficient. For larger label sets, consider loading the existing labels into a Bash associative array once for O(1) lookups.
| # rules are already JSON. | ||
| # | ||
| # The canonical implementation remains scripts/label-classify.py in the hub, | ||
| # which never runs in CI. tests/test-classifier-parity.py asserts this file |
There was a problem hiding this comment.
⚪ LOW RISK
Nitpick: The documentation references a Python test file (tests/test-classifier-parity.py) for parity, but the PR description and code comments state that Python is strictly banned in the estate. Clarify the discrepancy in policy enforcement.
6dca64e to
38ddb95
Compare
Up to standards ✅🟢 Issues
|
Ships the canonical label set and the classifier that labels newly-filed issues. Additive only: it never removes a label, never overrides a human's classification, stays silent when unsure, and never fails an issue. Also adds this repo's two new workflows to .github/workflows/actions.lock as '[]'. That lock is keyed by workflow path and refuses any workflow it does not list -- a startup_failure, which produces no check run and is therefore silent. `gh actions-lock` cannot add these: it records action versions, and both workflows deliberately use no actions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
38ddb95 to
72e6559
Compare
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
1 participant
Ships the canonical label set and the classifier that labels newly-filed issues.
Additive only — never removes a label, never overrides a human's classification, silent when unsure, never fails an issue.
Also adds this repo's two new workflows to
.github/workflows/actions.lockas[]. That lock is keyed by workflow path and refuses any workflow it does not list — astartup_failure, which produces no check run and is therefore silent.gh actions-lockcannot add these: it records action versions, and both workflows deliberately use none.See
docs/LABELS.adocin hyperpolymath/.git-private-farm.🤖 Generated with Claude Code