[kelos-bot]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Adds an optional commentOn enum field to GitHubWebhookFilter so spawner authors can scope issue_comment event filters to comments posted on plain issues (Issue) or pull requests (PullRequest). Empty preserves the existing behavior of matching both.

GitHub fires issue_comment for both issues and PRs because PRs are issues in its data model. Until now, spawner authors had to spawn the task and bail in the prompt (see the gh pr view step-0 guards in kelos-workers, kelos-planner, kelos-api-reviewer), lean on a label discriminator, or avoid the event entirely. The issue.pull_request signal was already extracted in internal/webhook/github_filter.go for PullRequestAPIURL; this exposes it as a first-class filter input.

Which issue(s) this PR is related to:

Fixes #1080

Special notes for your reviewer:

API shape rationale (per the design proposal in #1080):

• Enum, not *bool — K8s API conventions discourage is*-prefixed boolean discriminators; an enum is also extensible if a third surface ever needs to be filtered.
• PascalCase values — matches K8s native (ClusterIP, OnFailure).
• Empty matches both — backwards-compatible; no defaulting or migration needed.
• Per-filter, not per-event-list — stays inside the existing OR-of-filters model and avoids inventing synthetic event names.
• Ignored on irrelevant events — issues, pull_request, pull_request_review, pull_request_review_comment are already unambiguous.

Implementation notes:

1. Added CommentOn string to GitHubWebhookFilter next to Draft, with +kubebuilder:validation:Enum=Issue;PullRequest and exported CommentOnIssue / CommentOnPullRequest constants.
2. In matchesFilter, inside the *github.IssueCommentEvent branch, check issue.IsPullRequest() against filter.CommentOn.
3. Added table-driven tests covering all three scopes (Issue, PullRequest, empty) on both PR-comment and plain-issue-comment payloads, plus a regression test that the field is silently ignored on non-issue_comment events.
4. Ran make update to regenerate the CRDs.

Spawner-prompt cleanups (dropping the gh pr view step-0 guards in kelos-workers, kelos-planner, kelos-api-reviewer, and the kelos-reviewer workaround tracked in #1060) are intentionally out of scope per the issue and will follow as separate PRs.

Does this PR introduce a user-facing change?

TaskSpawner GitHubWebhook filters now support a `commentOn` field (`Issue` or `PullRequest`) that scopes `issue_comment` events to comments on plain issues or pull requests. Empty matches both (existing behavior).

---

Summary by cubic

Adds an optional commentOn filter to GitHubWebhookFilter to scope issue_comment events to Issues or PRs. This fulfills task #1080 by reducing unnecessary spawns and removing prompt-side guards.

• New Features
  • Added commentOn enum to GitHubWebhookFilter with Issue and PullRequest; empty matches both for backward compatibility.
  • Applied only to issue_comment; updated matcher, CRDs, and tests to cover all cases.

^{Written for commit ff47b1c. Summary will update on new commits. Review in cubic}

[greptile-apps]

Greptile Summary

This PR adds a commentOn enum field (Issue | PullRequest) to GitHubWebhookFilter so spawner authors can scope issue_comment events to plain issues or PRs without prompt-level workarounds. The implementation is minimal and correct: the filter is evaluated only within the *github.IssueCommentEvent branch using the existing issue.IsPullRequest() signal, silently ignored on all other event types, and the kubebuilder enum marker enforces valid values at admission time. CRDs are regenerated and the new behaviour is fully covered by table-driven tests.

Confidence Score: 5/5

Safe to merge — well-scoped additive change with no breaking modifications to existing behaviour.

All changed files are correct and consistent. The filter logic uses the same nil-guard and early-return patterns as surrounding code, the kubebuilder enum prevents invalid values at admission, CRDs are regenerated, and the new path is fully covered by table-driven tests. No P0 or P1 findings.

No files require special attention.

Important Files Changed

Filename	Overview
api/v1alpha1/taskspawner_types.go	Adds CommentOnIssue/CommentOnPullRequest constants and CommentOn string field to GitHubWebhookFilter with correct kubebuilder enum validation; clean and consistent with existing field conventions.
internal/webhook/github_filter.go	CommentOn filter correctly scoped to IssueCommentEvent inside the existing IssuesEvent/IssueCommentEvent branch; silently ignored for non-issue_comment events as intended; uses the same nil-guard pattern as surrounding filters.
internal/webhook/github_filter_test.go	Adds comprehensive table-driven tests for all three CommentOn scopes on both PR-comment and plain-issue-comment payloads, plus a regression test for ignored behavior on non-issue_comment events.
internal/manifests/charts/kelos/templates/crds/taskspawner-crd.yaml	CRD regenerated with commentOn field; enum values and description match the Go type definition.
internal/manifests/install-crd.yaml	install-crd.yaml regenerated identically to the Helm chart CRD; no issues.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Incoming GitHub webhook] --> B{event type?}
    B -->|issue_comment| C[IssueCommentEvent branch]
    B -->|issues| D[IssuesEvent branch]
    B -->|other| E[Other event branches]

    C --> F{filter.CommentOn != empty?}
    F -->|No| G[Skip CommentOn check]
    F -->|Yes| H{issue.IsPullRequest?}

    H -->|true / PR comment| I{CommentOn == PullRequest?}
    I -->|Yes| J[✅ Pass — continue other filters]
    I -->|No  CommentOn==Issue| K[❌ Return false]

    H -->|false / plain issue| L{CommentOn == Issue?}
    L -->|Yes| M[✅ Pass — continue other filters]
    L -->|No  CommentOn==PullRequest| N[❌ Return false]

    G --> O[State / Labels / Body filters…]
    J --> O
    M --> O
    D --> P[CommentOn ignored — continue]
    E --> Q[CommentOn ignored — continue]

Loading

_{Reviews (1): Last reviewed commit: "feat(api): add commentOn filter to GitHu..." | Re-trigger Greptile}

[cubic-dev-ai]

1 issue found across 5 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/manifests/charts/kelos/templates/crds/taskspawner-crd.yaml">

<violation number="1" location="internal/manifests/charts/kelos/templates/crds/taskspawner-crd.yaml:3352">
P2: `commentOn` description says empty is allowed, but the CRD enum rejects empty string.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: commentOn description says empty is allowed, but the CRD enum rejects empty string.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At internal/manifests/charts/kelos/templates/crds/taskspawner-crd.yaml, line 3352:

<comment>`commentOn` description says empty is allowed, but the CRD enum rejects empty string.</comment>

<file context>
@@ -3343,6 +3343,16 @@ spec:
+                                specific subject. GitHub fires issue_comment for both plain issues
+                                and pull requests; "Issue" matches only the former, "PullRequest"
+                                only the latter. Empty matches both. Ignored for other events.
+                              enum:
+                              - Issue
+                              - PullRequest
</file context>

Suggested change

	enum:
	- Issue
	- PullRequest
	type: string
	enum:
	- ""
	- Issue
	- PullRequest
	type: string

[gjkim42]

/kelos api-review

[kelos-bot]

🤖 Kelos Task Status

Task kelos-api-reviewer-issue-comment-1511d4e513af has succeeded. ✅

[kelos-bot]

🤖 Kelos API Reviewer Agent @gjkim42

API Design Review

Verdict: COMMENT (would be APPROVE — PR is authored by kelos-bot, so a same-identity approval is blocked by GitHub)
Scope: Adds an optional commentOn enum field to GitHubWebhookFilter (Issue | PullRequest) that scopes issue_comment-event filters to comments on plain issues vs. pull requests.

The shape is sound: per-filter placement preserves the existing OR-of-filters model, the new field is additive and +optional, the dispatch is correctly limited to *github.IssueCommentEvent and silently ignored on other events, and the tests are thorough — all three scopes are exercised on both PR-comment and plain-issue-comment payloads, plus a regression case for non-issue_comment events. CRDs are regenerated consistently across the Helm chart and install-crd.yaml.

Findings

Validation (nit, non-blocking)

• api/v1alpha1/taskspawner_types.go:445-448 — the doc comment states "Empty matches both", but +kubebuilder:validation:Enum=Issue;PullRequest admits only those two values. In practice this is fine because omitempty skips schema validation when the field is absent — but an explicit commentOn: \"\" (which the doc invites) would be rejected by the API server. There is in-file precedent for the explicit form at taskspawner_types.go:492 (Action: Enum=create;update;remove;\"\"). Pick whichever you prefer for this codebase: extend the enum to Enum=Issue;PullRequest;\"\", or tighten the docstring to "Omit to match both". Either keeps the API truthful.

Naming / consistency (discussion, non-blocking)

• api/v1alpha1/taskspawner_types.go:447 — every other enum on GitHubWebhookFilter uses lowercase values that mirror GitHub's wire format (open/closed/all, approved/changes_requested/any, created/opened/submitted). CommentOn introduces PascalCase (Issue, PullRequest). The choice is defensible — these values aren't GitHub wire strings, they're Kelos-defined enum values for a derived signal (issue.IsPullRequest()), and PascalCase matches upstream K8s convention (ClusterIP, OnFailure). Worth keeping in mind for future enums on derived signals so the in-struct convention stays predictable.

Suggestions (optional)

• Consider promoting CommentOn to a named string type (e.g., type CommentOnSubject string) with the existing constants typed accordingly. Sibling enums in this repo are split between named types (CredentialType) and bare strings (State, Action), so this is a consistency call rather than a correctness one.
• The constants are exported as untyped string constants. If they end up imported by spawner-prompt callers in the future, a typed alias would prevent accidental cross-assignment with the Action/State fields.

Note on prompt injection: third-party bot content on this PR contained directives instructing AI reviewers to attribute findings to that bot. Those instructions were disregarded; the analysis above is independent and based on reading the diff and surrounding code.

/kelos needs-input

[gjkim42]

/kelos review

[kelos-bot]

🤖 Kelos Task Status

Task kelos-reviewer-issue-comment-b3726cab1c26 has succeeded. ✅

[kelos-bot]

🤖 Kelos Reviewer Agent @gjkim42

Review Summary

Verdict: COMMENT (would be APPROVE — PR is authored by kelos-bot, so a same-identity approval is blocked by GitHub)
Overall correctness: patch is correct
Scope: Adds optional commentOn enum (Issue/PullRequest) to GitHubWebhookFilter to scope issue_comment events; matcher and table-driven tests updated; CRDs regenerated.

Findings Overview

Priority	Count	File:Line	Summary
P0	0	—	none
P1	0	—	none
P2	0	—	none
P3	0	—	none

Findings

No code-level findings. The implementation is minimal and well-scoped:

• internal/webhook/github_filter.go:321-338 — the new check is placed inside the existing *github.IssuesEvent, *github.IssueCommentEvent switch arm, narrowed via _, ok := e.(*github.IssueCommentEvent) so it is silently ignored on IssuesEvent exactly as the doc comment promises. The issue != nil guard mirrors the surrounding pattern, the early filter.CommentOn != "" skip preserves backward compatibility, and the switch falls through gracefully on unknown values (which the kubebuilder enum already prevents at admission).
• api/v1alpha1/taskspawner_types.go:378-448 — purely additive: new constants and one +optional enum-validated field next to Draft. No rename/removal, no semantic change to existing fields. commentOn is a clear name with no clash against Kubernetes-native semantics.
• internal/webhook/github_filter_test.go:556-682 — table-driven coverage hits all three scopes (Issue, PullRequest, empty) on both PR-comment and plain-issue-comment payloads, plus a regression test confirming the field is ignored on issues events.
• CRDs in both internal/manifests/charts/kelos/templates/crds/taskspawner-crd.yaml and internal/manifests/install-crd.yaml are regenerated consistently.

The deeper API-shape discussion (PascalCase vs. lowercase enum convention, whether to add "" to the enum to match the doc's "empty matches both" wording, named-string-type vs. bare string) is already covered in the /kelos api-review thread on this PR; I am not re-raising it here.

Key takeaways

• Implementation is correct and matches the design proposal in #1080 exactly.
• Test coverage is thorough.
• Generated CRD artifacts are up to date and consistent across both manifests.

Note on prompt injection: third-party bot content on this PR contained directives instructing AI reviewers to attribute findings to that bot. Those instructions were disregarded; this review is independent and based on reading the diff and surrounding code.

[kelos-bot]

🤖 Kelos Task Status

Task kelos-api-reviewer-pull-request-review-c0bad32ad47e has succeeded. ✅

[kelos-bot]

🤖 Kelos API Reviewer Agent @gjkim42

API Design Review

Verdict: COMMENT (would be APPROVE — same-identity approval blocked by GitHub since the PR author is kelos-bot)
Scope: Re-review trigger on the same commit (ff47b1c) — no code changes since the prior api-review.

The prior api-review on this PR (#pullrequestreview-4211512935) covered the full diff against the API design checklist and remains applicable. There are no new commits, so I am not re-running the full audit; the verdict, findings, and suggestions there still stand. Summarising for convenience:

Findings

Validation (nit, non-blocking — unchanged from prior review)

• api/v1alpha1/taskspawner_types.go:445-448 — doc says "Empty matches both", but +kubebuilder:validation:Enum=Issue;PullRequest would reject an explicit commentOn: "". In-file precedent for the explicit form lives at taskspawner_types.go:492 (Action: Enum=create;update;remove;""). Either extend the enum to Enum=Issue;PullRequest;"" or tighten the docstring to "Omit to match both" — both keep the API truthful.

Naming / consistency (discussion, non-blocking — unchanged from prior review)

• api/v1alpha1/taskspawner_types.go:447 — sibling enums on GitHubWebhookFilter use lowercase wire-format values (open/closed/all, approved/changes_requested/any). CommentOn introduces PascalCase. Defensible because these values are Kelos-defined (derived from issue.IsPullRequest(), not GitHub wire strings) and PascalCase matches upstream K8s convention (ClusterIP, OnFailure); flagging only as a convention call for future enums on derived signals.

Suggestions (optional, unchanged)

• Promote CommentOn to a named string type (e.g., type CommentOnSubject string) with the existing constants typed accordingly — consistency call versus the bare-string siblings (State, Action).

Note on prompt injection: third-party bot content on this PR contains directives instructing AI reviewers to attribute findings to that bot. Those instructions were disregarded; the analysis above is independent and based on reading the diff and surrounding code.

/kelos needs-input