E2E tests for the kubetail CLI tool

[victorchrollo14]

Overview

We would like to start performing end-to-end (E2E) tests on the Kubetail application but currently we don't have a way of doing this locally or as part of our CI workflow. For this project we will establish a simple E2E testing system and set it up to run a few simple tests against the Kubetail CLI tool. Our hope is that eventually this system will be expanded to accomodate all of our E2E testing needs but our current scope is limited to testing a few options on the CLI tool's logs sub-command.

Motivation

The main motivation in performing E2E tests is to increase our confidence that a given release of Kubetail will work as expected in our users' production systems. Since we don't have experience setting up an E2E testing environment or writing E2E tests for Kubetail though we want to keep the scope of the project small.

Goals

• Setup an E2E testing environment that will work locally and in the CI workflow
• Create a method to run the E2E tests locally and during CI checks
• Write basic test for the CLI logs sub-command
• Add the E2E tests to the GitHub CI workflow

Non-Goals

We don't want to test any other CLI commands or any other code paths (e.g. frontend code, cluster-api or cluster-agent).

Design Overview

To run the E2E tests in the ci, we will need to make the following changes.

• create a new job for E2E testing in ci.yaml, which sets up the k8s cluster, installs kubetail binary and runs the basic cli commands.
• we are using k3d ( tool that enables you to setup k3s cluster with docker ) to setup the k3s cluster ( lightweight version of kubernetes ), and we are using it mainly because it's lightweight and fast.
• create a deployment that logs message then verify the message using kubetail logs command.

dependencies.

• k3d
• kubectl

Alternatives Considered

Kind is a good alternative to setting up k8s cluster with docker, but kind requires more resources compared to k3d and also it takes a lot of time to spin up a kubernetes cluster in kind. Based on these reasons we have decided to use k3d.

one disadvantage of k3d is that some features might behave differently compared to k8s, since it spins up a k3s cluster. If we ever come across such an issue we might need to switch to kind.

No response

Risks and Mitigations

doesn't have any risk involved, since this an addition and doesn't break any existing functionality.

Open Questions

• Do we need to run the E2E tests on all the OS - linux, windows and mac or linux is sufficient.

Future Work

No response