Thank you for your interest in contributing to the Kubernetes provider. We welcome your contributions. Here you'll find information to help you get started with provider development.
Our provider development documentation provides a good start into developing an understanding of provider development. It's the best entry point if you are new to contributing to this provider.
To learn more about how to create issues and pull requests in this repository, and what happens after they are created, you may refer to the resources below:
Clone repository to: $GOPATH/src/github.com/hashicorp/terraform-provider-kubernetes
$ mkdir -p $GOPATH/src/github.com/hashicorp; cd $GOPATH/src/github.com/hashicorp
$ git clone [email protected]:hashicorp/terraform-provider-kubernetes
Enter the provider directory and build the provider
$ cd $GOPATH/src/github.com/hashicorp/terraform-provider-kubernetes
$ make build
Statically linking binaries can be required for testing development builds in containers not providing all dependencies, e.g.:
# CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"'
In order to prevent breaking changes and migration of user-created resources, resources included in this provider will be limited to stable (aka v1
) and beta APIs (with beta resources, readiness for inclusion will be assessed individually). You can find v1
resources in the Kubernetes API documentation for the appropriate version of Kubernetes.
If you wish to work on the provider, you'll first need Go installed on your machine (version 1.9+ is required). You'll also need to correctly setup a GOPATH, as well as adding $GOPATH/bin
to your $PATH
.
To compile the provider, run make build
. This will build the provider and put the provider binary in the $GOPATH/bin
directory.
$ make build
...
$ $GOPATH/bin/terraform-provider-kubernetes
...
In order to test the provider, you can simply run make test
.
$ make test
In order to run the full suite of Acceptance tests, run make testacc
.
Note: Acceptance tests create real resources, and often cost money to run.
$ make testacc
In general, adding test coverage (unit tests and acceptance tests) to new features or bug fixes in your PRs, and sharing the logs of a successful test run on your branch will greatly speed up the acceptance of your PR. Most of our tests can be run against a kind
cluster, so no additional infrastructure is required.