feat: triage variable to control auto-coding#331
Conversation
Adds a new variable to the triage agent that allows you to control whether it automatically triggers the coding agent. With the variable set to true (default) you get the current behaviour: the issue is labelled as `ready-to-code`, which triggers the coding agent automatically. When the variable is set to false, issues will be marked with `triaged` instead, and a human (or alternate agent) can decide when to add the `ready-to-code` label or `/fs-code` comment. Fixes #1750. Signed-off-by: Tim deBoer <git@tdeboer.ca>
Functional tests did not runThe
|
PR Summary by QodoAdd TRIAGE_AUTO_CODE flag to gate ready-to-code promotion
AI Description
Diagram
High-Level Assessment
Files changed (5)
|
Code Review by Qodo
Context used✅ Compliance rules (platform):
55 rules 1. Protected paths modified
|
| # Set TRIAGE_AUTO_CODE=false to disable the automatic ready-to-code | ||
| # promotion. When disabled, low-risk categories receive "triaged" instead, | ||
| # requiring human review before the code agent runs. | ||
| TRIAGE_AUTO_CODE="${TRIAGE_AUTO_CODE:-true}" |
There was a problem hiding this comment.
2. Unvalidated auto-code flag 🐞 Bug ☼ Reliability
scripts/post-triage.sh treats any TRIAGE_AUTO_CODE value other than the exact string "false" as enabled, so typos/case variants (e.g., "FALSE", "0", "fasle") will still apply "ready-to-code" and can unintentionally trigger the coding agent.
Agent Prompt
### Issue description
`TRIAGE_AUTO_CODE` is documented as a boolean (`true`/`false`) but is only checked via `[[ "${TRIAGE_AUTO_CODE}" == "false" ]]`. Any other value (including common misconfigurations like `FALSE`) silently behaves like `true`, potentially auto-applying `ready-to-code`.
### Issue Context
- Docs state valid values are strictly `true` and `false`.
- The post-triage script currently defaults to enabled for all non-exact-false values.
### Fix Focus Areas
- scripts/post-triage.sh[319-352]
- docs/triage.md[131-139]
### Proposed fix
1. Normalize the value (e.g., lowercase) and validate explicitly:
- `TRIAGE_AUTO_CODE="${TRIAGE_AUTO_CODE:-true}"`
- `TRIAGE_AUTO_CODE="${TRIAGE_AUTO_CODE,,}"`
- `case "${TRIAGE_AUTO_CODE}" in true|false) ;; *) echo "ERROR: TRIAGE_AUTO_CODE must be true|false"; exit 1 ;; esac`
2. Keep the existing branching logic, but now it can rely on a known-good value.
3. (Optional) Mention in docs that values are case-sensitive unless normalization is implemented.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
/fs-review |
|
🤖 Finished Review · ✅ Success · Started 1:20 PM UTC · Completed 1:35 PM UTC |
ReviewFindingsMedium
Low
Labels: PR modifies triage agent configuration and post-script behavior. |
The review agent flagged docs/code.md as an issue because it says the 'ready-to-code' label was "unconditionally applied" and this PR changes that. That's not really an issue b/c the triage agent already applied the label only in certain cases, but it does highlight that the code agent docs contain unnecessary details of triage (which will require changes when triage changes; agents and their docs should be self-sufficient) and internal details (post-script). This just simplifies to clean that up and only contain what the user needs to know. Signed-off-by: Tim deBoer <git@tdeboer.ca>
|
The [stale-doc] above wasn't accurate, but it did highlight that the code agent docs had an overly detailed and unnecessary reference to triage agent. Second commit added to fix that. |
rh-hemartin
left a comment
There was a problem hiding this comment.
LGTM, but you need to resolve the last Qodo comment
Adds a new variable to the triage agent that allows you to control whether it automatically triggers the coding agent. With the variable set to true (default) you get the current behaviour: the issue is labelled as
ready-to-code, which triggers the coding agent automatically. When the variable is set to false, issues will be marked withtriagedinstead, and a human (or alternate agent) can decide when to add theready-to-codelabel or/fs-codecomment.Fixes #1750.