-
For small changes or quick fixes, a simple pull request is sufficient.
-
For non-trivial changes or bug reports, please file an issue before submitting a pull request.
-
For substantial changes, or to discuss a feature request, prefix your issue with "RFC:" (Request For Comment) and tag it with the label
rfc
.
For local dev builds, the term dev
is used in place of the release tag for the final image tag.
There are make
targets for each build
and test
variant.
Make Target | Description |
---|---|
|
Builds local image tagged as |
|
Runs unit tests against image tag |
|
Builds local image tagged as |
|
Runs unit tests against image |
where:
-
<image>
defaults tojgriff/k8s-resource
-
<major.minor>
are thekubectl
versions we are currently shipping (see the Makefile).
Build new local jgriff/k8s-resource:latest
:
make build_latest
Build a single, specific kubectl
variant (jgriff/k8s-resource:dev-kubectl-1.22
):
make build_1.22
Build all kubectl
variants (dev-kubectl-<each-kubectl-version>
):
make build
Test a single, specific variant:
make test_1.22
Run unit tests across all dev
image variants:
make test
Combine targets in single invocation:
make build_1.22 test_1.22
Sometimes, you may need to push your dev images to another (private) registry for integration testing or other uses. In those scenarios, you have 2 basic options:
-
Make another tag from source image
jgriff/k8s-resource
after every dev build.make build_latest docker tag jgriff/k8s-resource:latest my-registry/k8s-resource:latest
However, this can get hairy for all the
kubectl
version variants and also requires some two-step scripting on your part. -
Override the
Makefile
variableIMAGE
to set it to your custom image name (without the tag).make build_latest IMAGE=my-registry/k8s-resource
This has the added benefit of working for every target. For example, to build all image variants with your custom image registry name:
make build IMAGE=my-registry/k8s-resource
Works with any target, such as
test
:make test IMAGE=my-registry/k8s-resource