This guide explains how to work on the Kashti codebase.
- Docker
- make
Begin by cloning this repository with your favorite Git tool.
$ git clone git@github.com:brigadecore/kashti.git
$ cd kashti
To ensure a consistent development environment for all contributors, Kashti relies heavily on Docker containers as sandboxes for all development activities including dependency resolution, executing tests, or running a development server.
make
targets seamlessly handle the container orchestration.
If, for whatever reason, you must opt-out of executing development tasks within
containers, set the SKIP_DOCKER
environment variable to true
, but be aware
that by doing so, the success or failure of development-related tasks, tests,
etc. will be dependent on the state of your system, with no guarantee of the
same results in CI.
All development-related tasks should "just work" on Linux and Mac OS systems. When developing on Windows, the maintainers strongly recommend utilizing the Windows Subsystem for Linux.
This blog post provides excellent guidance on making the Windows Subsystem for Linux work seamlessly with Docker Desktop (Docker for Windows).
To execute dependency resolution (i.e. yarn install
):
$ make yarn-install
Note that if any NPM modules have binary extensions, this will build those extensions for use within the container (i.e. for Linux).
Generally, you do not need to explicitly execute dependency resolution because
it is automatically executed before other common make
targets:
To execute lint checks:
$ make lint
To execute tests:
$ make test
To execute e2e tests:
$ make e2e
To run the ng development server (in a container, of course):
$ make serve
To build a Docker image for Kashti:
$ make build
By default, built images are named using the following scheme:
kashti:<version>
. If you wish to push customized or experimental images
you have built from source to a particular org on a particular Docker registry,
this can be controlled with environment variables.
The following, for instance, will build images that can be pushed to the
krancour
org on Dockerhub (the registry that is implied when none is
specified).
$ DOCKER_ORG=krancour make build
To build for the krancour
org on a different registry, such as quay.io
:
$ DOCKER_REGISTRY=quay.io DOCKER_ORG=krancour make build
Images built with names that specify registries and orgs for which you have
write access can be pushed using make push
. Note that the
build
target is a dependency for the push
target, so
the build and push processes can be accomplished together like so:
$ DOCKER_REGISTRY=quay.io DOCKER_ORG=krancour make push-all-images
Note also that you must be logged into the registry in question before attempting this.
Kashti can be run locally via make serve
.
To install in a Kubernetes development cluster, we recommend using the Helm Brigade chart
located in the brigadecore/charts repo. As of Brigade chart version 0.19.3
, Kashti
is installed by default. (Kashti can also be installed standalone via its chart.)
If you are running Minikube, you can do a full build of this repo into a Docker image and run it (without even having to push to a remote registry):
$ eval $(minikube docker-env)
$ make build
$ helm repo add brigade https://brigadecore.github.io/charts
$ helm install -n brigade brigade/brigade --set image.repository=krancour --set image.tag=123456
Then, use brig dashboard
to start a tunnel to the Kashti pod inside your cluster.