Output Filtering

[brampling]

A user must be able to filter output from BotKube executor commands (e.g. kubectl) with simple string matching. This should be analogous to how users use grep when running kubectl from the command line. grep and grep-like syntax are not requirements.

AC

• Command output can be filtered using simple string matching
• Filtering is a CommandFlag and usable across any executor command
• Only matching output lines are returned to the user
• There is an indication that output is filtered
• There is an indication when there is output but no filter matches
• There is an indication when there is no output (i.e. no match/no output errors are differentiated)

Nice to have: more advanced filtering than simple string matching (e.g. RegEx, grep-style syntax, etc.). This should only be implemented if it comes from an existing package and we can do it with a clean UX.

Notes

• Behavior - one of them:
  - Dedicated flag (@botkube kubectl logs <pod> --filter 'grep string and maybe params')
  • Piping @botkube kubectl logs <pod> | filter "str"
• Support it globally - kubectl and other commands
• Naming: filter - we won't support full grep functionality
• No highlight on communication platforms
• Collect anonymous analytics
• Only grep for now / or instead of using binary, use some existing Go library
• Include it in integration tests
• Interactive option - out of scope -> will be done in a separate task

[lpetkov]

Prototypes (2 flows): https://www.figma.com/proto/UcaGQ1UiBziOQbNPmSwE0T/grep?page-id=0%3A1&node-id=2%3A173&viewport=163%2C220%2C0.08&scaling=scale-down&starting-point-node-id=2%3A173&show-proto-sidebar=1

[ezodude]

The --filter is now under review, and the PR has been feature integrated with the interactive option.

Extra effort was required to ensure the text filter is resilient, works with edge cases and can be run from different contexts.

• Dedicated flag (@botkube kubectl logs --filter 'some filter value')
• Support it globally - kubectl and other commands
• Collect anonymous analytics
• Include it in integration tests

Follow up tickets

@lpetkov @brampling would appreciate your input.

Advanced filtering than simple string matching

This includes filters that use RegEx, grep-style syntax, etc... A bit of work is required to add this.

Also, these format can be triggered by supplying an extra flag. E.g. --re to signify that the supplied filter text should be handled differently.

Specifically,

• Handling incorrect expressions supplied by users.
• Updating both Interactive UI and regular kubectl with errors messages for incorrect expressions.
• Reworking the executor filter algorithm to correctly remove the --filter flag before running downstream commands.
• Guarding against errors from edge cases.

Further filtering

Currently, interactive filtering offers the ability to re-filter the original output.

Having run this a few times on Slack, the perceived expected behaviour was to further filter on the output from the original filter.

Supporting this will require some minor investigation.

[pkosiec]

Reopening until we have a last missing piece: documentation 🙂

[ezodude]

Documentation now in review.

[ezodude]

Documentation is complete.