DEV Community: Blair Rampling

Botkube v0.17.0 Release Notes

Blair Rampling — Thu, 12 Jan 2023 16:43:47 +0000

Botkube v0.17.0 is here, and it's huge! We've introduced a plugin system for sources and executors along with the first plugin for Helm. Botkube is the most modern ChatOps tool for Kubernetes!

This release is a major upgrade for Botkube. Kubernetes users are embracing all kinds of new tools and technologies for their application delivery workflows. GitOps and other DevOps tooling is changing the way Kubernetes is managed and monitored and automating a lot of the traditional processes. We wanted to go beyond the Kubernetes basics of monitoring the Kubernetes event stream and running kubectl commands. We decided to do that by implementing a plugin system that allows anyone to build a plugin for Botkube to add sources and executors.

With the addition of plugins in v0.17.0 combined with actions, which were added in v0.16.0, Botkube gains the ability to tie almost any tools together in the Kubernetes/CNCF ecosystem. Botkube is growing into an API automation engine that can listen for events from any source and respond with automated actions via any executor, all while reporting in to channels in your communication platform.

If you have any feature requests or bug reports, reach out to us on Slack or submit a Github issue

Plugin System

We have introduced a plugin system to Botkube in v0.17.0. This allows anyone to write new plugins for sources and executors and those plugins can be published for other Botkube users to install and use. We'll be leading the way with our own plugins, including the first executor plugin included in this release.

Botkube has two ways of interacting with APIs and other tools, sources and executors. Sources are event sources, so any tool that sends events or notifications can be integrated into Botkube and those events and notifications can be sent to communication channels based on the configured source bindings. Kubernetes native events are an example of a source and have been included in Botkube since the beginning. Executors are used to run commands from other tools from within a chat channel. The output of the command is then returned back to the channel where the command was run and can be filtered if needed. The original executor in Botkube is kubectl, and we have added a helm plugin with this release.

We will be publishing documentation and tutorials on the Botkube plugin system soon so you can design and create your own plugins. We are also working on additional plugins including the first new source plugin for Prometheus.

Helm Plugin

Along with the plugin system, we have introduced Helm as the first executor plugin for Botkube. The Helm plugin allows you to run Helm commands right from your communication platform. The Botkube Helm plugin provides a subset of the most useful Helm commands, you can list installed releases, rollback upgrades, and even install charts and uninstall releases.

Imagine seeing an alert in your communications platform that a deployment was updated but something went wrong and the new release is failing. You can check the application pod logs, the helm release status, then run @botkube helm rollback <release> and fix the problem without ever leaving the chat!

See the documentation for how to enable and use the Helm plugin. Much like the kubectl executor, Helm is disabled by default and when enabled, only allows read-only operations by default. You can enable write actions if you want, and you can even segregate those to specific, more restricted channels in your communication platform.

Kubectl Prefix Required

The kubectl executor was the only executor available in older versions of Botkube. With the addition of the Botkube plugin system and additional executor plugins, kubectl has company. You now need to specify the executor when running commands with Botkube. For kubectl this would be something like @botkube kubectl get pods, and we've even added the aliases @botkube k and @botkube kc to save you some typing. For Helm it would look like @botkube helm list. We added a notification about this to the help message in Botkube v0.16.0, but as of v0.17.0 the implied kubectl (i.e. @botkube get pods) will no longer work.

Botkube Command Tidying

There were some inconsistencies in how Botkube commands were structured in previous versions. We put some effort into unifying the command structure. Now all Botkube commands follow the same @botkube <verb> <object> structure. For example: @botkube notifier start is now changed to @botkube enable notifications. You can see a list of all of the changed commands in the changelog.

Bug Fixes

We have also fixed a couple of small bugs in Botkube that were reported to us by users and found by us. You can see the full list of changes in the changelog.

We appreciate your bug reports and pull requests! If you notice a bug in Botkube, please report it as a GitHub issue and we are happy to collaborate with you on getting it resolved.

Feedback - We’d Love to Hear From You!

As always, we want to hear your feedback and ideas about Botkube. Help us plan the Botkube roadmap, get the features you’d like implemented, and get bugs fixed quickly.

You can talk to us in the Botkube GitHub issues, Botkube Slack community, or email our Product Leader at blair@kubeshop.io.

Getting Started with the New Botkube Slack App

Blair Rampling — Wed, 14 Dec 2022 15:18:08 +0000

The new Botkube Slack app provides more great interactive features and better security when compared to the legacy Botkube Slack app. We announced the new socket mode Slack app in the Botkube v0.14.0 release notes. The new Slack app has some specific requirements and a new installation process, so let's have a look at how to get started with the most modern ChatOps tool for Kubernetes!. You can also use the Botkube installation documentation to get started, but this post is to give you more context about the changes to the new app and some caveats to watch out for.

This blog post assumes that we're starting a completely new Botkube installation.

Requirements:

A Slack workspace where you have permission to install apps and create channels
A Kubernetes cluster where you have access to install Botkube
Working kubectl and helm installations

Multi-cluster caveat: The architecture of socket-based Slack apps is different from the older Slack app. If you are using Botkube executors (e.g. kubectl commands) and have multiple Kubernetes clusters, you need to install a Botkube Slack app for each cluster. This is required so that the Slack to Botkube connections go to the right place. We recommend you set the name of each app to reflect the cluster it will connect to in the next steps.

Installing the Slack App in your workspace

Let's go through the initial steps for installing the socket-based Slack app itself in your Slack workspace.

Open the Slack App Console and click Create an App or Create New App.
Click "From an app manifest" as we will use the Botkube-provided manifest for the new app.

Select the workspace into which you want to install the app and click Next.
You can find the latest app manifests in the Botkube documentation. There are three different YAML manifests available. The manifests vary based on whether you want to use Botkube in a public Slack channel, a private channel, or both. This is one of the new improved security features that limits the scope of the token that Botkube uses. This is an example of the manifest for both public and private channels:

display_information:
 name: Botkube
 description: Botkube
 background_color: "#a653a6"
features:
 bot_user:
   display_name: Botkube
   always_online: false
oauth_config:
 scopes:
   bot:
     - channels:read
     - groups:read
     - app_mentions:read
     - chat:write
     - files:write
settings:
 event_subscriptions:
   bot_events:
     - app_mention
 interactivity:
   is_enabled: true
 org_deploy_enabled: false
 socket_mode_enabled: true
 token_rotation_enabled: false

If you are using Botkube with multiple Kubernetes clusters as mentioned in the earlier caveat, set the name and description fields to something specific to the cluster this app will manage. This will make it clear in Slack itself which bot maps to which cluster. Paste this YAML into the app manifest dialog and click Next.

You now have a chance to review the app settings. Click the Create button.
Click the Install to Workspace button to add this newly created app to the Slack Workspace.

Review the permissions and click Allow. The app is now installed in your Slack workspace.

Botkube Slack App Tokens

Now that the Slack app is installed in your workspace, you can proceed to installing Botkube in your Kubernetes cluster. First, you need two tokens, a bot token and an app-level token. This is another additional security measure in the new Slack app. You can see details on these token types in the Slack documentation. You will use these tokens in the Botkube installation process.

From the Slack app page where you left off after installing the app in your workspace, select OAuth & Permissions in the left navigation bar.
Copy the Bot User OAuth Token shown here.

Click Basic Information in the left navigation bar.
Scroll down to the App-Level Tokens section and click the Generate Token and Scopes button.
Give the token an appropriate name and click Add Scope.
Select the connections:write scope, then click the Generate button.

Copy the created token and click Done.

Invite Botkube to a channel

Now that everything is set up for the Slack app, you need to invite the Botkube bot to a Slack channel. This is the channel that you will use for notifications and command execution and is required for the Botkube configuration before it is installed in Kubernetes.

You should see a new Slack bot in your workspace under "Apps" with the name that you specified in the manifest. You can create a new Slack channel or use an existing one. Whether the channel is public or private, make sure that you used the correct manifest earlier when creating the app. If the wrong manifest was used you will see error messages in the Botkube logs about the scope.

Invite the bot to the channel. The easiest way to do this is to open the Slack channel and send a message to @. You will be prompted to add the bot to the channel, click the Add to Channel button.

Installing Botkube

We now have everything we need to configure and install Botkube. We will use helm to install it in a Kubernetes cluster. First, configure some environment variables that we will pass to the helm install command.

The Slack app bot token from earlier:

export SLACK_API_BOT_TOKEN="xoxb-{botToken}"

The Slack app-level token from earlier:

export SLACK_API_APP_TOKEN="xapp-{appToken}"

The cluster name that will be used when interacting with this instance of Botkube. Notifications and other interactive commands will use this name to reference this cluster:

export CLUSTER_NAME={cluster_name}

Set to true to allow execution of kubectl commands, false to make this bot instance for event notifications only:

export ALLOW_KUBECTL={allow_kubectl}

Specify the Slack channel name where you invited the bot earlier. Make sure you do not include the # in the channel name:

export SLACK_CHANNEL_NAME={channel_name}

Now that those five environment variables are set, make sure you have the Botkube helm repository configured:

helm repo add botkube https://charts.botkube.io
helm repo update

Now you can simply run the helm install command shown here, or copy from the documentation. Note that this installs version v0.16.0 of Botkube which is the latest version as of this article:

helm install --version v0.16.0 botkube --namespace botkube --create-namespace \
--set communications.default-group.socketSlack.enabled=true \
--set communications.default-group.socketSlack.channels.default.name=${SLACK_CHANNEL_NAME} \
--set communications.default-group.socketSlack.appToken=${SLACK_API_APP_TOKEN} \
--set communications.default-group.socketSlack.botToken=${SLACK_API_BOT_TOKEN} \
--set settings.clusterName=${CLUSTER_NAME} \
--set executors.kubectl-read-only.kubectl.enabled=${ALLOW_KUBECTL} \
botkube/botkube

If everything goes according to plans, you will see Botkube start up in the Slack channel and print the initial interactive help menu.

Botkube is now ready to go!

Explore the New Slack App

The new Botkube Slack app adds some great features that weren't previously available, particularly around interactive event response. You saw the interactive help at the end of the installation process in the previous section. You can click the buttons in the interactive help to run the commands as shown. You can also make configuration changes interactively, try clicking the Adjust notifications button and you can set notification settings using a dialog rather than editing YAML.

Another interactive feature is the Run command option shown with events. Any time an event is sent to the channel, you can select a contextual command from the Run command drop-down box. The list of commands will be only those relevant to the resource type in the event. Selecting a command will use the kubectl executor to run the command against the specific resource in the event. This saves typing out the kubectl commands by hand if you want to quickly get some information about a resource, like describe a new resource or get logs on a pod with errors.

Another interactive feature can be found by running @botkube kubectl with no options. This starts the interactive command generator. This presents you with a list of verbs that you can run and as you make selections, automatically offers the contextually-relevant options in drop-down boxes until you have built a complete command. You can then click the Run command button and see the resulting output. You can also filter the output by specifying a match string in the Filter output box.

What Could Go Wrong?

There are several steps in the process to look out for. These are where things could go wrong and you could end up with a Botkube installation that doesn't work. Always check the Botkube pod logs for details on why something might not be working, but here are a few things to look out for:

Slack App Manifest Scope: When using the YAML app manifest to create the Slack app, make sure you use the appropriate version for public, private, or both Slack channel types.
Slack app-level token scope: The app-level token needs to have the connections:write scope assigned.
Multiple clusters: When using Botkube to execute commands in multiple Kubernetes clusters, you need to install a Slack app for each cluster to ensure the commands are routed to the correct one. If you are using Botkube for notifications only and have command execution disabled, you can get away with a single app for multiple clusters. If you ever do want to enable command executions though, you will need to revert to the Slack app per cluster model.
Incorrect tokens: Make sure your bot and app-level tokens are correct and match those in the Slack App Console.
Slack channel configuration: Make sure you omit the # when specifying the Slack channel that Botkube will use.

Feedback - We’d Love to Hear From You!

As always, we want to hear your feedback and ideas about Botkube. Help us plan the Botkube roadmap, get the features you’d like implemented, and get bugs fixed quickly.
You can talk to us in the Botkube GitHub issues, Botkube Slack community, or email our Product Leader at blair@kubeshop.io.

Botkube v0.16.0 Release Notes

Blair Rampling — Thu, 01 Dec 2022 17:22:06 +0000

The latest version of Botkube is here, v0.16.0. Like peanut butter and chocolate, we've brought together two great parts of Botkube to make your life working with Kubernetes even ~~tastier~~ easier. Botkube is the most modern ChatOps tool for Kubernetes!

We've addressed two things that have been frequently requested by users. First, we've added a more configurable filter system for events, meaning you can better filter what kind of events you want to see. Second, we've added actions, which can be configured to run commands automatically when an event is received and the command output is included with the event. These features work behind the scenes in the Botkube engine and are not specific to any communication platform.

If you have any feature requests or bug reports, reach out to us on Slack or submit a Github issue

Filters

Botkube now has additional event and resource constraints that you can use to filter events when you're defining sources. Sources define the event stream you want to watch and are then bound to a communication channel that will receive all matching events.

In earlier versions of Botkube you could create sources based on Kubernetes resource type (e.g. Pod, ConfigMap, etc.), Namespace, and event type (e.g. Create, Delete, Error). This is useful for getting all events of a certain type in a namespace, for example, but in some cases still results in a lot of events that aren't relevant to all users in a channel. In addition, this doesn't provide the granular level of control needed to automatically act on events (see Actions below!).

In Botkube v0.16.0 we've added the following event filter criteria:

labels and annotations: These filters simply have to (exactly) match the labels or annotations applied to a resource in order for the event to be logged.
name: This is a Regex field to match resource names. Events pertaining to any resource that matches the specified pattern will be logged.
event.reason and event.message: These are Regex fields to match the event reason and event message. Events matching the specified pattern will be logged.

The new filter criteria have lots of great uses. You may have a suspect resource like a flaky pod, for example. Now you can create a "flaky pod" Slack channel and send error events pertaining to that suspect pod with the specific failure reason to that Slack channel and monitor when and how often those failures occur.
They also enable Botkube actions!

Actions

Along with the new, more granular filter options, we have introduced actions to Botkube. Actions allow you to automatically trigger a specific command when a matching event occurs. You can have more context for an event delivered directly to your communication channels with no additional manual work.

Actions consist of two parts, the command and the source binding. The command is the specific executor command that will be run by the action. In v0.16.0 only the kubectl executor is available but more will be coming soon. The command itself is defined using the Go template syntax and allows you to pass the event metadata in order to build the command you need. The source binding specifies the event source that will trigger the action and uses the same sources that can be bound to communication channels. These sources use the event filters discussed earlier.

When a source is bound to both an action and a communication channel, the results of the action command are delivered to the communication channel along with the original event. Actions can be used to get information using the default read-only kubectl configuration. If you want, you can even configure the executor to allow other actions beyond those that are read-only. You could have Botkube restart a hang pod automatically, for example, and the results will be sent to the communication channel along with the event.

There are two preconfigured actions included with Botkube to help you get started quickly, they are disabled by default:

describe-created resource: This action runs the kubectl describe command against the resource associated with an event. It is bound to the default k8s-create-events source by default. When enabled, the command will be run each time a resource is created and the event is logged by the k8s-create-events source. The results of the kubectl describe command will then be attached to the event and delivered to any channel to which the k8s-create-events source is bound.
show-logs-on-error: This action runs kubectl logs against a resource. It is bound to the k8s-err-with-logs-events source by default. Any event captured by this source (triggered by error event types) will include the output of the kubectl logs command and be delivered to any communication channel to which it is bound.

Legacy Slack App Deprecation

With the release of the new Socket-mode Slack app in Botkube v0.14.0, the legacy Slack app is being deprecated. In the next version (v0.17.0), it will no longer be supported in the Botkube app and Botkube will need to be configured to use the new Slack app.

This change is happening because Botkube requires the socket-mode Slack app for the new interactivity features we introduced in Botkube v0.15.0. We plan to put all of our development efforts into this new app so we can continue to build great interactive features. In addition, Slack is recommending the migration from the legacy app type to socket mode as it introduces more granular permissions for bot users and OAuth tokens. This means you have more control over what Botkube and other Slack apps can do in your Slack workspace.

Slack will be unapproving the legacy Botkube Slack app in their Slack App Directory on December 21, 2022. After this date you will still be able to install the legacy Slack app using the Add to Slack button in the legacy Slack installation guide but you will receive a warning that the app is not authorized by the Slack App Directory. You will need to accept this warning to proceed if you want to keep using the legacy Slack app with Botkube v0.16 or earlier.

Bug Fixes

We have also fixed a couple of small bugs in Botkube that were reported to us by users and found by us. You can see the full list of changes in the changelog.

We appreciate your bug reports and pull requests! If you notice a bug in Botkube, please report it as a GitHub issue and we are happy to collaborate with you on getting it resolved.

Feedback - We’d Love to Hear From You!

As always, we want to hear your feedback and ideas about Botkube. Help us plan the Botkube roadmap, get the features you’d like implemented, and get bugs fixed quickly.

You can talk to us in the Botkube GitHub issues, Botkube Slack community, or email our Product Leader at blair@kubeshop.io.

Botkube v0.15.0 Release Notes

Blair Rampling — Thu, 17 Nov 2022 13:44:37 +0000

We have an exciting early release of Botkube, just in time for KubeCon! We've been working as fast as we can to get some great new features ready to release. Here's v0.15.0 of Botkube, the most modern ChatOps tool for Kubernetes!

v0.15.0 adds some great interactivity features aimed at application developers who may not be Kubernetes experts.

If you have any feature requests or bug reports, reach out to us on Slack or submit a Github issue

In this release, we focused on interactivity with Botkube and the kubectl executor. Some of the enhancements are currently Slack-specific using the additional interactive capabilities of the new Slack app. We plan to enhance other platforms with interactive features where technically feasible.

Interactive kubectl

If you're using the new Slack app, you can now use kubectl interactively. Simply run @botkube kubectl (or use the alias k or kc) and you will see an interactive kubectl command builder. Select the verb (get, in this example) and you can select the object type to get. Once you have selected those, based on context, you can select a namespace and, optionally, a specific object to act on. Leaving out the object will generally show the list of available objects. Once you've made your selections, you can see a preview of the constructed command. You can also specify a filter string to apply to the output (more about that later!) and click Run command. The command runs and you can see the output in the channel as usual.

This interactive kubectl tool is especially useful for developers and other users who want to see information about their applications but might not be Kubernetes and kubectl experts.

Actionable Events

If you're receiving events in the new Slack app, you can now run contextual actions right from the event message. When a pod error comes in, for example, you can run kubectl commands that are relevant to the pod object right from the "Run command" drop-down box. The command runs automatically without any typing and returns the output in the channel. This makes it quick an easy to start investigating your alerts.

Output Filtering

You can now filter the output of any command you run with Botkube, on any platform. Simply run the command with the - filter "string" flag and you will only see the matching output. The filter flag does simple linewise string matching. Any line in the output with a matching string will be shown, lines without a match are discarded.

Interactive Output Filtering

Output filtering is even easier if you're using the new Slack app. When you run a command with a lot of output (>15 lines) you will see a Filter output box. If you type a string in the box and press enter, you will then see the output of the previous command filtered to only show lines matching the filter string. This is great for quickly sifting through logs of a problematic pod, for example.

Bug Fixes

We have also fixed a couple of small bugs in Botkube that were reported to us by users and found by us. You can see the full list of changes in the changelog.

We appreciate your bug reports and pull requests! If you notice a bug in BotKube, please report it as a GitHub issue and we are happy to collaborate with you on getting it resolved.

Feedback - We'd Love to Hear From You!

As always, we want to hear your feedback and ideas about Botkube. Help us plan the Botkube roadmap, get the features you'd like implemented, and get bugs fixed quickly.

You can talk to us in the Botkube GitHub issues, Botkube Slack community, or email our Product Leader at blair@kubeshop.io.

Botkube v0.14 Release Notes

Blair Rampling — Thu, 17 Nov 2022 13:41:05 +0000

In the previous release of Botkube we promised to accelerate the pace of development and release. Well, here is another new release of Botkube, the most modern ChatOps tool for Kubernetes!

BotKube v0.14.0 addresses a number of community-suggested issues and adds some great features to help you control the notification levels you receive from your Kubernetes clusters.

If you have any feature requests or bug reports, reach out to us on Slack or submit a Github issue

In this release, we focused on improvements to the Botkube onboarding experience and notification tuning, persistent settings, and bug fixes. Some of the enhancements are currently Slack-specific using the additional interactive capabilities of the new Slack app. We plan to enhance other platforms with interactive features where technically feasible.

Dynamic notification setting changes

We've received frequent feedback from users about the notification settings in Botkube. By default, Botkube monitors and shows all Kubernetes events in a configured communication channel. Previously, this could only be configured in the YAML configuration or during the Helm installation/upgrade.

You can now also configure notification settings right from the Botkube interface in your communication platform. Using the command @Botkube edit SourceBindings you can select the notifications you want to receive. After choosing the notifications, the configuration is dynamically updated with an automatic brief restart of Botkube.

New Botkube Slack App

We have created a brand new Botkube Slack app. The new app uses the Slack Socket Mode which provides a much more robust platform for interactivity and uses the new Slack permissions model for enhanced security.

You will see many enhancements to Botkube in Slack in this and upcoming releases. For example, you can use the interactive selector to change the notification settings mentioned earlier. Just run @Botkube, edit SourceBindings without specifying the notification level, and you can select the sources from an interactive dialog.

The installation process has changed for the new Slack app. See the installation guide to get started with the enhanced interactive experience.

The legacy Slack app is still available, but will be deprecated in future versions.

Improved Help

The @Botkube help command has been enhanced when using the new Botkube Slack app. Run @Botkube help and you will see an interactive help message. You can click any of the buttons in the interactive help to run the commands, change settings, and more.

This new, interactive help will enable new Botkube users to get up and running even faster. You can also send us feedback and access documentation and additional external help resources directly from the interactive help.

Persistent Settings

Changes to settings made from the Botkube interface, such as notifier start/stop, notification level settings, and filter enable/disable now persist across Botkube restarts. In earlier versions, these settings would reset to the settings in the Botkube configuration file upon restarting the Botkube pod.

Mattermost v7 Support

Botkube now supports Mattermost version 7.x! See the installation guide for Mattermost to get started.

Bug Fixes

We have fixed several bugs in BotKube that were reported to us by users. We also spent some time refactoring code and increasing test coverage to improve the quality of BotKube. You can see the list of bug fixes in the changelog.

We appreciate your bug reports and pull requests! If you notice a bug in BotKube, please report it as a GitHub issue and we are happy to collaborate with you on getting it resolved.

Feedback - We'd Love to Hear From You!

As always, we want to hear your feedback and ideas about BotKube. Help us plan the BotKube roadmap, get the features you'd like implemented, and get bugs fixed quickly.

You can talk to us in the BotKube GitHub issues, BotKube Slack community, or email our Product Leader at blair@kubeshop.io.

Botkube v0.13 Release Notes

Blair Rampling — Thu, 17 Nov 2022 13:31:55 +0000

BotKube, welcome to Kubeshop! We're happy to have the most modern ChatOps tool for Kubernetes join the team.

BotKube v0.13.0 is the first release under Kubeshop and the newly formed dedicated Botkube team. We are picking up the pace of development and you can expect to see more frequent BotKube releases with lots of new, great features and bug fixes.

If you have any feature requests or bug reports, reach out to us on Slack or submit a Github issue

In this release, we focused on multi-channel support, bug fixes, and optimizing the BotKube release pipeline.

Multi-Channel Support

While BotKube is now part of the Kubeshop team, BotKube development is still community-driven. Multi-channel support was requested by several users in the BotKube community and the reason why we implemented it in our first release. We also worked with the community to review the configuration proposal and will continue this kind of community involvement as we go.

BotKube now supports multiple channels and communication tools using a single BotKube installation in your Kubernetes cluster. You can group and send events to different channels and tools. For example, some events are sent as Slack chat messages for an immediate response and others to ElasticSearch for archiving. You can even have multiple instances of these tools and send specific events to different channels in each of them. This previously required multiple BotKube installations in a cluster or complex annotations. You can also toggle filters and recommendations per-rule now, where filters and recommendation settings were global in previous versions.

In future releases, we plan to streamline this source to channel mapping further and make the configuration even easier.

It is also possible to configure the executor configuration on a per-channel basis, so that kubectl permissions can be controlled. You can set different kubectl permissions that restrict the commands, resources, and namespaces users in a specified channel can access. This is great for environments with multi-tenant Kubernetes clusters where teams use separate namespaces.

We have simplified and enhanced the BotKube configuration syntax to enable the new multi-channel support. If you are running BotKube v0.12.4 (or earlier) using a default configuration, you can specify an updated configuration when using the helm upgrade command. If you are using a custom configuration, see the changelog for details on the configuration syntax changes. You can modify your config.yaml file with the new structure and pass that to the helm upgrade -f command.

You can also see the configuration details for sources and executors in the BotKube documentation.

Bug Fixes

We appreciate your bug reports and pull requests! If you notice a bug in BotKube, please report it as a GitHub issue and we are happy to collaborate with you on getting it resolved.

Release Pipeline Enhancements

We are working on improving the BotKube release pipeline with each release. Our goal is to fully automate the release pipeline, so that we can collect all pull requests in a release branch, perform automated end-to-end testing with the various communication platforms, and build and release the BotKube container image.

In this release we have cleaned up the overall CI pipeline and automated end-to-end testing of BotKube on Slack. As we add more automation, BotKube releases will be more frequent and more reliable.

Telemetry

BotKube has introduced anonymized telemetry collection in v0.13.

Why: We are collecting this telemetry data in order to focus our development efforts on the communication tools and actions that BotKube users are using the most.

What:All data is anonymized. We use UUIDs in order to aggregate telemetry from individual BotKube installations. Other data that could identify users or environments is redacted, such as namespace names, pod names, etc. For transparency, we collect the following data:

BotKube version
Kubernetes version
Names of enabled integrations (notifiers and bots)
Handled events in anonymized form, grouped by the integration (communication platform) name
For each event, we collect its type (e.g. create or delete), resource API Version and resource Kind. Any custom resource API groups or Kinds are excluded from the analytics collection.
Executed commands in anonymized form
For kubectl commands, only the command verb is collected. Resource name and namespace are excluded from the analytics collection.
App errors (crashes, configuration and notification errors)
For identifying BotKube installations, we use unique identifiers generated in the following way:
As an anonymous cluster identifier, we use the uid of kube-system Namespace,
As an anonymous installation identifier, we use UUID generated during Helm chart installation and persisted in a ConfigMap.

Opt-out: You can opt out of telemetry collection by setting the analytics.disable: true parameter when installing or upgrading the Helm chart. This prevents all analytics collection and we do not track the installation and opt-out actions.

Please see the BotKube Privacy Policy for more details.

Feedback - We'd Love to Hear From You!

As always, we want to hear your feedback and ideas about BotKube. Help us plan the BotKube roadmap, get the features you'd like implemented, and get bugs fixed quickly.

You can talk to us in the BotKube GitHub issues, BotKube Slack community, or email our Product Leader at blair@kubeshop.io.