ci: add /kind, /area, /milestone label sync for issues#2157
Conversation
Mirrors pr-kind-label.yaml so directive based labeling works on issues just like PRs. prow-github.yml is still the only thing handling these commands on issues. Removing it (a separate change) would otherwise regress issue triage. Body only trigger for now and no issue_comment handling. There is therefore no new comment triggered attack surface. Ref: llm-d#956 Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
There was a problem hiding this comment.
Pull request overview
Adds an issue-focused GitHub Actions workflow to mirror the existing PR body directive label sync, so /kind, /area, and /milestone directives in issue bodies can drive labels/milestone without relying on the prow-github.yml chat-ops integration.
Changes:
- Introduces a new
issues-triggered workflow that parses/kind,/area, and/milestonedirectives from the issue body. - Applies/removes
kind/*andarea/*labels and sets the issue milestone viagh issue editwithissues: writepermissions.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (1)
.github/workflows/issue-kind-label.yaml:55
- Same failure mode for
/area: if the directive contains a non-existentarea/*label, the workflow will remove all existingarea/*labels and then fail to add the requested one(s), effectively wiping area triage. Consider validating requestedarea/*labels exist before removing current labels; otherwise no-op and warn.
# Remove existing area/* labels
gh issue view "$ISSUE_NUMBER" --repo "$REPO" --json labels \
-q '.labels[].name | select(startswith("area/"))' | \
while IFS= read -r label; do
gh issue edit "$ISSUE_NUMBER" --repo "$REPO" --remove-label "$label" || echo "::warning::Failed to remove label '$label'"
The label sync steps removed all kind/* and area/* labels before adding the ones named in the body. A mistyped directive made the add fail while the removal had already happened, leaving the issue or PR unlabeled with only a warning in the Actions log. Issue templates do not scaffold these directives and the repository defines just two area/* labels, so an unrecognised value is easy to hit. Check every requested label against the repository label list first and skip the sync entirely when any is unknown. Review comment from co=pilot: - llm-d#2157 (review) Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
An empty /kind extraction still removed existing kind/* labels which wiped labels maintainers set through the UI on any body edit. Exit early when no directive is present matching the /area step and issue-kind-label.yaml. Review comment from Copilot: - llm-d#2157 (review) Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
Comments suppressed due to low confidence (2)
.github/workflows/pr-kind-label.yaml:72
- The value printed in this workflow command comes from the PR body and is not escaped. GitHub Actions workflow commands interpret percent-encoded sequences (e.g.
%0A), so a crafted directive value could inject additional workflow commands into logs/annotations. Escape%(and ideally other control chars) before interpolating untrusted text into::warning::messages.
if [ -n "$unknown" ]; then
echo "::warning::Unknown label(s) ${unknown% }, skipping area sync"
exit 0
fi
.github/workflows/issue-kind-label.yaml:69
- The value printed in this workflow command comes from the issue body and is not escaped. GitHub Actions workflow commands interpret percent-encoded sequences (e.g.
%0A), so a crafted directive value could inject additional workflow commands into logs/annotations. Escape%(and ideally other control chars) before interpolating untrusted text into::warning::messages.
if [ -n "$unknown" ]; then
echo "::warning::Unknown label(s) ${unknown% }, skipping area sync"
exit 0
fi
Values pulled from the PR/issue body were echoed into ::warning:: workflow commands unescaped. GitHub decodes percent sequences in command data, so escape %, CR and LF before emitting untrusted text. This commit hardens the workflows. Review comment: - llm-d#2157 (review) Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
elevran
left a comment
There was a problem hiding this comment.
One minor consistency nit below.
|
|
||
| on: | ||
| issues: | ||
| types: [opened, edited] |
There was a problem hiding this comment.
nit:
types: [opened, edited] omits reopened, which pr-kind-label.yaml includes for the same trigger. If reopening an issue can leave a stale label state, add reopened for parity; otherwise fine as is.
What type of PR is this?
/kind feature
What this PR does / why we need it:
Mirrors
pr-kind-label.yamlso directive based labeling works on issues just like PRs.prow-github.ymlis still the only thing handling these commands on issues. Removing it (in #2114) would otherwise regress issue triage.Implementation: Body only trigger for now and no
issue_commenthandling. There is therefore no new comment triggered attack surface.Note for reviewers:
An alternative implementation is body plus
issue_comment: [created]which gives full Prow parity and is gated on author_association inOWNER/MEMBER/COLLABORATOR. Adds anissue_commenttriggered workflow holdingissues: writewhich is precisely the surface area #2114 is trying to reduce (increases potential attack surface). Gated comment commands can be added later if maintainers are missing their use in practice. For this implementation it is worth re-evaluating the marketplaceslash-commandaction because comment triggers are what those actions are built for (ref: #2113 (comment))./cc @elevran
Which issue(s) this PR fixes:
Partial: #956
Raised in review on #2113:
/areaand/milestonecommands to PR label sync #2113 (comment)/areaand/milestonecommands to PR label sync #2113 (comment)Release note (write
NONEif no user-facing change):