feat: support discussion_comment event

[wadackel]

Summary

Extend command-action to handle discussion_comment events alongside issue_comment so IssueOps commands can be triggered from comments on GitHub Discussions, reusing the number / context output redesign introduced by #100.

Implementation:

• Add resolveCommentContext() in src/main.ts that normalizes both event types into { kind: 'issue' | 'pull_request' | 'discussion', number, commentId, actor } and returns null for unsupported events. isValidContext() now receives kind: CommentKind and validates uniformly via allowedContexts.includes(kind) — the previous length === 1 switch is gone.
• Extend validContexts and the allowed_contexts default with "discussion" (default becomes issue,pull_request,discussion). Update the allowed_contexts input description, the context output description, and the number output description to list all three values.
• For discussion_comment: emit number = payload.discussion.number, context = "discussion", plus comment_id / actor. issue_number is intentionally not emitted for discussions. For issue_comment (issue or PR), behavior is unchanged from feat(output): add number and context outputs, soft-deprecate issue_number #100.
• Update the unsupported-event warning to list both accepted events (issue_comment and discussion_comment).

Tests (src/main.test.ts, 54 → 58 cases):

• discussion accept (default allowed_contexts)
• allowed_contexts="issue" rejects a discussion comment via the filter
• allowed_contexts="discussion" accepts a discussion comment (single-context positive)
• allowed_contexts="discussion" rejects an issue_comment (heterogeneous)
• Expanded unsupported-event test asserts the warning lists both event names

Docs:

• New ### Triggering from GitHub Discussions Tips subsection with a hardened workflow example and a security callout linking to GitHub Actions security hardening.
• The existing Getting Started example is also hardened to pass IssueOps params through env: rather than interpolating ${{ ... }} directly into a run: script. Discussion / Issue / PR comment content is attacker-controlled, so interpolating it into a shell command is an expression-injection sink.
• README Inputs/Outputs tables regenerated by pnpm generate.

Generated:

• dist/index.js and dist/index.js.map regenerated via pnpm build.

Migration

For existing v1 consumers, no migration is required. Workflows that only listen to issue_comment are unaffected. Workflows that want to support discussions:

1. Add on: discussion_comment: types: [created].
2. Switch from outputs.issue_number to outputs.number (already recommended by feat(output): add number and context outputs, soft-deprecate issue_number #100).
3. (Optional) Add permissions: discussions: write if your follow-up step writes back to the discussion (e.g. reactions via GraphQL).

References

• Closes feat: support discussion_comment event #101
• Extends feat(output): add number and context outputs, soft-deprecate issue_number #100 (number / context output redesign)
• GitHub Webhooks: discussion_comment

Test plan

• pnpm typecheck exits 0
• pnpm lint (oxlint --max-warnings=0) exits 0 with 0 warnings / 0 errors
• pnpm test passes 58/58 (was 54; +4 new tests + 1 expansion)
• pnpm format:check clean
• pnpm generate and pnpm build are idempotent (md5sum determinism check)
• CI green

[github-actions]

🎉 This PR is included in version 2.2.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀