Dispatch on code-review comments?

[asford]

This is an incredible repo, amazing code and even better docs. 👏👏👏

One minor nitpick, would it be possible to teach the dispatch to operate on PR review comments. Right now github doesn't dispatch an issue_comment event for a "top level" review comment, even though it shows up like a comment in the PR thread. I believe it dispatches a pull_request_review event, and from a quick peak at main.js I don't think slash-command-dispatch will be able to process these events?

slash-command-dispatch/src/main.ts

Lines 16 to 31 in 2ce216d

	// Check required context properties exist (satisfy type checking)
	if (
	!github.context.payload.action ||
	!github.context.payload.issue ||
	!github.context.payload.comment
	) {
	throw new Error('Required context properties are missing.')
	}
	// Only handle 'created' and 'edited' event types
	if (!['created', 'edited'].includes(github.context.payload.action)) {
	core.warning(
	`Event type '${github.context.payload.action}' not supported.`
	)
	return
	}

@peter-evans Do you think this would be feasible?

[peter-evans]

@asford Thank you. I'm glad you are finding this action useful.

It might be feasible, but I'll need to investigate a bit and think about how the action could support both regular comments and pull request review comments. Perhaps pull_request_review_comment is the event which is triggered for all review comments, including the final "top level" review comment.

One possible problem is that the command workflow which runs as a result of the dispatch would not be able to set reactions on the comment when it completes with create-or-update-comment action. That action only works for issue and pull request comments. That means a new action would likely be required to handle review comments. Further, if you wanted the slash command to work in both comment types (issue and review) then the command workflow would need to be written to support that. (This assumes you care about having feedback to the comment containing the slash command)

[asford]

That's an excellent point I hadn't thought about. We're currently just posting-pack to the PR that issues the slash command in a separate, rather than targeting the exact comment that launched the command. You're right that things are going to get ...hairy... when you start writing a workflow that tries to interaction with both issue comments and PR review comments separately.

It looks like the content of the review (entered as the top-level review summary on an approve/changes/comment action) is included as the "review.body" property of the pull_request_review object returned on the pull_request_review event payload. I think this would be where we'd expect the slash command, if at all, direct comments on the unified diff from pull_request_review_comment would be weird-to-me, but maybe relevant for some.

It sounds like, if anything, we'd be getting into here-be-dragons territory in terms of the comment_payload if repository dispatch were used. You'd be tucking in of an issue_comment, pull_request_review or pull_request_review_comment. We'd likely adopt workflow dispatch for these events, if only to keep the command dependencies clear, but this then breaks the validation feedback example you provided. Trying to work with these different payload types on the receiving side would be a ...challenging... choice.

[peter-evans]

After looking into this a bit more I think it's feasible to modify the action to support this, however, I think it would end up complicating the use of this action and any command workflows that would need to support both regular issue comments and review comments. Unless there is a really compelling reason to add this I'm leaning towards not supporting this for now. Do you have a good reason for needing this feature? Or is it just a "nice to have?"