feat(api): add commentOn filter to GitHubWebhookFilter

Merged
KE
6mo ago
+182-0

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.