Contributing to k8gb §

k8gb is licensed under Apache 2 License and accepts contributions via GitHub pull requests. This document outlines the resources and guidelines necessary to follow by contributors to the k8gb project.

Getting started §

Getting help §

Feel free to ask for help and join the discussions at k8gb community discussions forum. We have dedicated #k8gb channel on Cloud Native Computing Foundation (CNCF) Slack, and we can also actively monitoring #sig-multicluster channel on Kubernetes Slack.

Reporting issues §

Reporting bugs is one of the best ways to contribute. Feel free to open an issue describing your problem or question.

Contribution flow §

Following is a rough outline for the contributor's workflow:

Local setup §

Deploy k8gb locally §

make deploy-full-local-setup

deploys k8gb from scratch, including:

Upgrade k8gb to local candidate §

make upgrade-candidate

performs upgrade of k8gb helm chart and controller to the testing version built from your current development tree.

Overriding dev environment settings §

Sometimes there is a need to override environment variables used by make targets for local k8gb development. This can be easily achieved by providing the list of environment variables with respective values in the .env file at the local repository root:

cat .env

# .env:

Overrides done this way can persist between terminal sessions and can be used as a single point of configuration for development in terminal and IDE of choice.

Testing §

Unit testing §

Use make test to check your implementation changes.

Testing against real k8s clusters §

There is a possibility to execute the integration terratest suite over the real clusters. For this, you need to override the set of test settings as in the example below.

PRIMARY_GEO_TAG=af-south-1 \
SECONDARY_GEO_TAG=eu-west-1 \ \
K8GB_CLUSTER1=arn:aws:eks:af-south-1:<aws-account-id>:cluster/k8gb-cluster-af-south-1 \
K8GB_CLUSTER2=arn:aws:eks:eu-west-1:<aws-account-id>:cluster/k8gb-cluster-eu-west-1 \
make terratest

Debugging §

  1. Install Delve debugger first. Follow the installation instructions for specific platforms from Delve's website.

  2. Run delve with options specific to IDE of choice. There is a dedicated make target available for Goland:

    make debug-idea

    This article describes possible option examples for Goland and VS Code.

  3. Attach debugger of your IDE to port 2345.

Code style §

k8gb project is using the coding style suggested by the Golang community. See the golang-style-doc for details.

Please follow this style to make k8gb easy to review, maintain and develop. Run make check to automatically check if your code is compliant.

Commit and Pull Request message §

We follow a rough convention for PR and commit messages, which is designed to answer two questions: what changed and why. The subject line should feature the what, and the body of the message should describe the why. The format can be described more formally as follows:

<what was changed>

<why this change was made>


The first line is the subject and should be no longer than 70 characters. The second line is always blank. Consequent lines should be wrapped at 80 characters. This way, the message is easier to read on GitHub as well as in various git tools.

scripts: add the test-cluster command

This command uses "k3d" to set up a test cluster for debugging.

Fixes #38

Commit message can be made lightweight unless it is the only commit forming the PR. In that case, the message can follow the simplified convention:

<what was changed and why>

This convention is useful when several minimalistic commit messages are going to form PR descriptions as bullet points of what was done during the final squash and merge for PR.

Signature §

As a CNCF project, k8gb must comply with Developer Certificate of Origin (DCO) requirement. DCO GitHub Check automatically enforces DCO for all commits. Contributors are required to ensure that every commit message contains the following signature:

>Signed-off-by: NAME SURNAME <>

The best way to achieve this automatically for local development is to create the following alias in the ~/.gitconfig file:

ci = commit -s

When a commit is created in GitHub UI as a result of accepted suggested change, the signature should be manually added to the "optional extended description" field.

Changelog §

The CHANGELOG is automatically generated from Github PRs and Issues during release. Use dedicated keywords in PR message or manual PR and Issue linking for clean changelog generation. Issues and PRs should be also properly tagged with valid project tags ("bug", "enhancement", "wontfix", etc )

Documentation §

If contribution changes the existing APIs or user interface, it must include sufficient documentation explaining the use of the new or updated feature. website § website is a Jekyll-based static website generated from project markdown documentation and hosted by GitHub Pages. gh-pages branch contains the website source, including configuration, website layout, and styling. Markdown documents are automatically populated to gh-pages from the main branch and should be authored there. Changes to the website layout and styling should be checked out from the gh-pages branch and PRs should be created against gh-pages.

Local website authoring and testing §

These instructions will help you to set up and use local website authoring and testing environment:

End-to-end demo helper §

The demo helper is designed to work with podinfo that was deployed by

make deploy-test-apps

It will configure podinfo to expose geotag as part of an HTTP response.

To test and/or demonstrate continuous query to GSLB enabled endpoint execute

make demo DEMO_URL=

The happy path will look like:

[Thu May 27 15:35:26 UTC 2021] ...

200  "message": "eu-west-1",

[Thu May 27 15:35:31 UTC 2021] ...

  "message": "eu-west-1",
[Thu May 27 15:35:36 UTC 2021] ...

The sources for demo helper images can be found here

To enable verbose debug output declare DEMO_DEBUG=1 like

make demo DEMO_URL= DEMO_DEBUG=1

Thanks for contributing!