epic: starship cli

[Anmol1696]

Overview

Currently we use make commands and some handy scripts like scripts/port-forward.sh to interact with the system.

Proposal

Create a go cli starship with the following commands:

• start: Read a config yaml file, and spin up k8s infra on the cluster, optionally create the kind cluster if local deployment
• stop: Delete all the helm deployments
• connect: Analogous to port forwarding
• setup: Initial setup and install all the binrarries required

The cli should be able to work on mac or linux initially (need tests to make sure this works)

Working

For the first iteration of the cli, we will just use exec commands from inside the binary. This would mean, we just need to port the current commands from various make and bash commands into the go cli."

APIs

Once the cli is working, for the developer, this should be following commands to get started

go get github.com/cosmology-tech/starship/cli

starship start --config config.yaml

Future work

• Automated resource allocation based on available resources
• Native support of multiple helm and others

Sub Tasks

• version in config: feature: add version for each of the config files to hold helm chart version #202
• port-forward check: improvements: port-forward should check status of deployments before running #145
• list: list all helm charts installed
• start: add ability to use --set, --set-file into the config file
• start: be able to parse the config file, run schema for verification before install
• status: be able to run kubectl get pods and helm status, to figure out the actual status of the helm charts

[Anmol1696]

Looking more closely into the implementation for the cli, it would make sense to have cli natively support helm, kubectl and kind commands.

Currently all the dependencies for the cli are in golang and have clients for it. It would be much cleaner and also should not take too much time (similar to the exec cmd method).

[Anmol1696]

This needs to be re-prioritized, since having a starship cli will help in quick on-boarding as well as cleaner integration.
Inshort the cli needs to replace the use of:

• helm
• port-forward script
• dev-setup script
• install.sh script
• yq, jq

We can assume the heavy use of kubectl with the starship cli.

This cli will also be used in the starship-action

[Anmol1696]

We should also add on the top of the config file, version:

version: <helm version>

chains:
- ...

The name of the helm deployment can be something that is generated or asigned, similar to docker run command.

[Anmol1696]

Maybe we can add another command to the cli, init so that we can scafold a starship dir with all the components required.
For example:

starship init

# should create a file structure
.github/workflows/      # optionally the starship workflow for the CI
  starship-tests.yaml
starship/
  configs/
    ci.yaml
    devnet.yaml
    local.yaml
  Makefile
  README.md
  tests/   # empty dir

The main thing we want to provide out of the box are:

• Various config files for different environments
• Makefile with all the handy commands
• Readme for getting started with it, how to initialize

Tests dir is very specific to the type of project this is used for. We can have additional kwargs for the init command for creating the tests/ dir with initial test cases even for go, js or rust.

[Anmol1696]

We will have to redo the whole starship cli, since the current flag and command mapping dont seem to work well.
Also at this stage the client is only good for debuging and using for local use and not production usage.

We will have to redefine the functions and options for each of the functions and start to define them individually.

[Anmol1696]

With starship js, this is not taken care of.