Christie Wilson
b5a4d7636f
To allow contributors to run the integration tests with their own GCS buckets and image repos (since not all contributors will have accesss to the projects used by the kaniko maintainers) this updates the integration tests so that these can be provided on the command line. This allows tests to be run individually, without using `make integration-test`. Previously, part of the test setup was done in the shell script (creating the context tarball that is required for the tests that build images with context). Instead it will be done in the test iself, so we can use `go test` to run tests individually if we want to. If we are running only one individual test, we don't want to build all of the images, so this commit creates a builder which tracks which images it has built and can be used by a tests to check if it should build an image before running, or it will use the images that have already been built by a previous test. The name of the context tarball has also been made unique (it includes the unix timestamp) to avoid potential test flakes if two tests using the same GCS bucket run simultaneously.
3.8 KiB
Development
This doc explains the development workflow so you can get started contributing to Kaniko!
Getting started
First you will need to setup your GitHub account and create a fork:
Once you have those, you can iterate on kaniko:
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/kaniko directory
in your GOPATH.
To check out this repository:
- Create your own fork of this repo
- Clone it to your machine:
mkdir -p ${GOPATH}/src/github.com/GoogleContainerTools
cd ${GOPATH}/src/github.com/GoogleContainerTools
git clone git@github.com:${YOUR_GITHUB_USERNAME}/kaniko.git
cd kaniko
git remote add upstream git@github.com:GoogleContainerTools/kaniko.git
git remote set-url --push upstream no_push
Adding the upstream remote sets you up nicely for regularly syncing your
fork.
Verifying kaniko builds
Images built with kaniko should be no different from images built elsewhere. While you iterate on kaniko, you can verify images built with kaniko by:
- Build the image using another system, such as
docker build - Use
container-diffto diff the images
Testing kaniko
kaniko 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
The integration tests live in integration and can be run with:
export GCS_BUCKET="gs://<your bucket>"
export IMAGE_REPO="gcr.io/somerepo"
make integration-test
If you want to run make integration-test, you must override the project using environment variables:
GCS_BUCKET- The name of your GCS bucketIMAGE_REPO- The path to your docker image repo
You can also run tests with go test, for example to run tests individually:
go test -v --bucket $GCS_BUCKET --repo $IMAGE_REPO -run TestLayers/test_layer_Dockerfile_test_copy_bucket
Requirements:
gcloudgsutilcontainer-diff- A bucket in GCS which you have write access to via
the user currently logged into
gcloud - An image repo which you have write access to via the user currently logged into
gcloud
These tests will be kicked off by reviewers for submitted PRs.
Creating a PR
When you have changes you would like to propose to kaniko, you will need to:
- Ensure the commit message(s) describe what issue you are fixing and how you are fixing it (include references to issue numbers if appropriate)
- 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.