Skip to content

Latest commit

 

History

History
85 lines (56 loc) · 2.7 KB

DEVELOPMENT.md

File metadata and controls

85 lines (56 loc) · 2.7 KB

Development

This doc explains the development workflow so you can get started contributing to Kritis!

Getting started

First you will need to setup your GitHub account and create a fork:

  1. Create a GitHub account
  2. Setup GitHub access via SSH
  3. Create and checkout a repo fork

Once you have those, you can iterate on kritis:

  1. Run your instance of kritis
  2. Run kritis tests

When you're ready, you can create a PR!

Checkout your fork

The Go tools require that you clone the repository to the src/github.com/GoogleContainerTools/kritis directory in your GOPATH.

To check out this repository:

  1. Create your own fork of this repo
  2. Clone it to your machine:
mkdir -p ${GOPATH}/src/github.com/grafeas
cd ${GOPATH}/src/github.com/grafeas
git clone git@github.com:${YOUR_GITHUB_USERNAME}/kritis.git
cd kritis
git remote add upstream git@github.com:grafeas/kritis.git
git remote set-url --push upstream no_push

Adding the upstream remote sets you up nicely for regularly syncing your fork.

Testing kritis

kritis has both unit tests and integration tests.

Unit Tests

The unit tests live with the code they test and can be run with:

make test

⚠️ These tests will not run correctly unless you have checked out your fork into your $GOPATH.

Integration tests

On a GCP project where Kritis has already been installed, this will prepare a new cluster named kritis-integration-test:

make -e GCP_PROJECT=<project id> setup-integration-local

As you develop, you can build new test images and run the integration test on demand:

make -e GCP_PROJECT=<project id> integration-local

Creating a PR

When you have changes you would like to propose to kritis, you will need to:

  1. Ensure the commit message(s) describe what issue you are fixing and how you are fixing it (include references to issue numbers if appropriate)
  2. Create a pull request

Reviews

Each PR must be reviewed by a maintainer. This maintainer will add the kokoro:run label to a PR to kick of the integration tests, which must pass for the PR to be submitted.