Send the cluster name for all interactive commands

[mszostok]

Description

Changes proposed in this pull request:

-Send the cluster name for all interactive commands

The current implementation is quite hacky. The main problem is that only buttons are easily to handle as we know the whole command up front and we can simply add --cluster-name flag.

For all others, like selects, inputs, etc. the command is constructed either via

botkube/pkg/bot/socketslack.go

Lines 517 to 544 in 428e624

	func resolveBlockActionCommand(act slack.BlockAction) (string, command.Origin) {
	cmd := act.Value
	cmdOrigin := command.UnknownOrigin
	switch act.Type {
	// currently we support only interactive.MultiSelect option
	case "multi_static_select":
	var items []string
	for _, item := range act.SelectedOptions {
	items = append(items, item.Value)
	}
	cmd = fmt.Sprintf("%s %s", act.ActionID, strings.Join(items, ","))
	cmdOrigin = command.MultiSelectValueChangeOrigin
	case "static_select":
	// Example of commands that are handled here:
	// @Botkube kcc --verbs get
	// @Botkube kcc --resource-type
	cmd = fmt.Sprintf("%s %s", act.ActionID, act.SelectedOption.Value)
	cmdOrigin = command.SelectValueChangeOrigin
	case "button":
	cmdOrigin = command.ButtonClickOrigin
	case "plain_text_input":
	cmd = fmt.Sprintf("%s%q", act.BlockID, strings.TrimSpace(act.Value))
	cmdOrigin = command.PlainTextInputOrigin
	}
	return cmd, cmdOrigin
	}

or by using state

botkube/internal/executor/kubectl/builder/kubectl.go

Line 393 in 428e624

func (e *Kubectl) extractStateDetails(state *slack.BlockActionStates) stateDetails {

.

This introduces additional complexity that we need to handle when we are injecting the --cluster-name flag as otherwise we will break the parsing on the plugin side.

Notes

I tried to use a new field, use ids, and slack message metadata, none of them worked for me 😞 So I ended up with this kinda ugly solution.

Future

Because of the current architecture, I cannot normalize it in a more straightforward way. IMO we should decouple slack commands and slack state. I would see sth like:

• clean cmd that is always passed to the plugin
• optional metadata which is map[string]string that holds the data that we extract from the Slack state. This way our plugins won't parse the initial slack state and as a result we can hold more details in the state that will be only handled in the core code.

Testing

• Install and play with the interactive kubectl or help message.

[josefkarasek]

lgtm 👍