We’d love your help!
BotKube is MIT Licensed and accepts contributions via GitHub pull requests. This document outlines some of the conventions on development workflow, commit message formatting, contact points and other resources to make it easier to get your contributions accepted.
We gratefully welcome improvements to documentation as well as to code.
You can contribute to documentation by following these instructions
depto manage dependencies.
dockerinstalled on your machine.
$ git clone https://github.com/infracloudio/botkube.git $GOPATH/src/github.com/infracloudio/botkube $ cd $GOPATH/src/github.com/infracloudio/botkube
Now you can build and run BotKube by one of the following ways
This will build BotKube and create a new container image tagged as
$ make build $ docker tag infracloud/botkube:latest <your_account>/botkube:latest $ docker push <your_account>/botkube:latest
<your_account> is Docker hub account to which you can push the image
Follow the instructions from README.md to deploy newly created image in your cluster.
# Set the container image $ helm install --name botkube --namespace botkube \ ... other options ... --set image.repository=your_account/botkube \ --set image.tag=latest ... helm/botkube
Build BotKube binary
If you don’t want to build the container image, you can build the binary like this,
# Fetch the dependencies $ dep ensure # Build the binary $ go build ./cmd/botkube/
config.yaml according to your needs. Please refer
configuration section from
documentation for more details
# From project root directory $ xdg-open config.yaml
Export the path to directory of
# From project root directory $ export CONFIG_PATH=$(pwd)
Make sure that correct context is set and you are able to access your Kubernetes cluster
$ kubectl config current-context minikube $ kubectl cluster-info Kubernetes master is running at https://192.168.39.233:8443 CoreDNS is running at https://192.168.39.233:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy ...
Run BotKube binary
Before making any significant changes, please open an issue. Discussing your proposed changes ahead of time will make the contribution process smooth for everyone.
Once we’ve discussed your changes and you’ve got your code ready,
make sure that build steps mentioned above pass. Open your pull
To avoid build failures in CI, run
# From project root directory $ ./hack/verify-*.sh
This will check if the code is properly formatted, linted & vendor directory is present.
Make sure your pull request has good commit messages:
Try to squash unimportant commits and rebase your changes on to develop branch, this will make sure we have clean log of changes.