Repository navigation
feat(pr-pipeline): start the issue lane on the Work status field_added trigger beside the label #13484
Description
Refs #7577
Slice 3 of 5 of #7577: label to Work status field cutover.
Outcome
work-resolve-issue.yml also starts on issues: field_added when the Work status field becomes agent-ready, beside the existing labeled trigger. GitHub documents field_added as firing when a field value is set or updated (Events that trigger workflows, issues, read 2026-11-05).
Change
- Add
field_addedto the workflow'sissuestypes, and gate the jobs on the event's field-value change toagent-ready, so a run fires only on that transition. - Keep the
labeledtrigger. With both live, one issue can produce two runs, so the concurrency group must collapse them into one.
Done when
- The first
field_addedrun logs a non-emptychanges.issue_field_value.fromand concludessuccess(work-items: work-item status as a field with labels as fallback #7577 done-when 3). - A label-triggered run and a field-triggered run for the same issue produce one lane run.
Blocked by #13483: readers must trust the field before the field starts the lane. A workflow edit, so it goes to the Automation Lanes builder.
Metadata
Metadata
Assignees
Type
Fields
Work status
agent-ready
Activity
github-actions commentedon Nov 5, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
I understood this as slice 3 of #7577.
work-resolve-issue.ymlwould also start onissues: field_addedwhen the Work status field becomesagent-ready. The existinglabeledtrigger stays, and the concurrency group collapses a label run and a field run for the same issue into one lane run. The scope and done-when items are exact, so I have no open questions. One done-when item, the firstfield_addedrun logging a non-emptychanges.issue_field_value.from, can only be checked after the workflow change is live. The issue says it is blocked by #13483. That issue is not in the open-issues list I was given, so I could not confirm its state and list no blocker. I found no duplicate among the open issues.Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Nov 5, 2026
Not admitted to the issue lane: its body or a criterion names .github/workflows/work-resolve-issue.yml, which the issue lane cannot push (patch-protected-path); a builder session takes it. Admission takes the issue once each of those is met, when intake triages it again (
.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Nov 5, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.8 remaining items
kyle-sexton commentedon Nov 6, 2026
ci(pr-pipeline): take the field_added actionlint ignore from standards
fix(actionlint): admit the issues field_added activity type (#952)
kyle-sexton commentedon Nov 6, 2026
The first
field_addedprobe run has a payload (run 42228210010). It came from the lanes App's Work status mirror write on #13710, at 13:46Z.actionfield_addedissue_field.id/.name/.field_type48484079/Work status/single_selectissue_field_value.option.id/.name84879218/needs-owner-decisionchanges.issue_field_value.from.option.id/.name86380002/confirmedsender.type/.idBot/337595936(the lanes App)The option sits under
option, not undersingle_select_optionas in the REST field-values response.changes.issue_field_value.fromis non-empty on an update. The trigger PR gates onissue_field.id,issue_field_value.option.idandsender.type == 'User'.fix(lanes): keep field writes out of the agent-ready label's run group
kyle-sexton commentedon Nov 6, 2026
The trigger shipped in #13716, merged 2026-11-06T14:15Z (949f152).
work-resolve-issue.ymlon main hastypes: [labeled, field_added], and the probe workflow is deleted.What a field change does now (hub decisions H72 and H73): when a listed person sets Work status to
agent-ready, admit checks the sender, logschanges.issue_field_value.from, and stops green. Theagent-readylabel still starts the work. The lanes App's own field writes start nothing. Field writes stay out of the label's concurrency group, so none can replace a waiting label run.Still open on this issue:
agent-ready. Any open issue works, since the run only logs and stops. The first such run must log a non-emptychanges.issue_field_value.fromand concludesuccess.Field-started work (the text-freeze and restart anchors) and the App's field path are owner calls on #13486.
kyle-sexton commentedon Nov 6, 2026
Done. Both criteria are met on main 949f152 (#13716).
field_addedrun, run 42241474462, concludedsuccess, and its "Log the Work status change" step logged a non-emptyfrom:{"from":{"option":{"id":86380002,"name":"confirmed"}},"to":{"option":{"id":84879220,"name":"agent-ready"}}}.admitran.pick-slot,resolve-issueand every later job were skipped, so a field change starts no lane run of its own and work starts only on the agent-ready label. Each issue therefore gets one lane run for a label plus a field change.Remaining parity (field-started work, the App field path) is tracked on #13486. The hourly mirror resets this issue's field to
confirmedfrom its labels.