Updating Contribution Guide (#2397)

_about/CONTRIBUTING.md

@@ -1,71 +1,122 @@
-## Developing the provider
+# Contributor Guide
 
-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.
+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.
 
-## Documentation
+If you want to learn more about developing a Terraform provider, please refer to the [Plugin Development documentation](https://developer.hashicorp.com/terraform/plugin).
 
-Our [provider development documentation](https://www.terraform.io/docs/extend/) 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.
+## Configuring Environment
 
-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:
-- [Issue creation and lifecycle](ISSUES.md)
-- [Pull Request creation and lifecycle](PULL_REQUESTS.md)
+1. Install Golang
 
+    [Install](https://go.dev/doc/install) the version of Golang as indicated in the [go.mod](../go.mod) file.
 
-## Building the provider
+1. Fork this repo
 
-Clone repository to: `$GOPATH/src/github.com/hashicorp/terraform-provider-kubernetes`
+    [Fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo) the provider repository and clone it on your computer.
 
-```sh
-$ mkdir -p $GOPATH/src/github.com/hashicorp; cd $GOPATH/src/github.com/hashicorp
-$ git clone git@github.com:hashicorp/terraform-provider-kubernetes
-```
+    Here is an example of how to clone this repository and switch to the directory:
 
-Enter the provider directory and build the provider
+    ```console
+    $ git clone https://github.com/<YOUR-USERNAME>/terraform-provider-kubernetes.git
+    $ cd terraform-provider-kubernetes
+    ```
 
-```sh
-$ cd $GOPATH/src/github.com/hashicorp/terraform-provider-kubernetes
-$ make build
-```
+    From now on, we are going to assume that you have a copy of the repository on your computer and work within the `terraform-provider-kubernetes` directory.
 
-Statically linking binaries can be required for testing development builds in containers not providing all dependencies, e.g.:
+1. Prepare a Kubernetes Cluster
 
-```
-# CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"'
-```
+    While our preference is to use [KinD](https://kind.sigs.k8s.io/) for setting up a Kubernetes cluster for development and test purposes, feel free to opt for the solution that best suits your preferences. Please bear in mind that some acceptance tests might require specific cluster settings, which we maintain in the KinD [configuration file](../.github/config/acceptance_tests_kind_config.yaml).
+
+    Here is an example of how to provision a Kubernetes cluster using the configuration file:
+
+    ```console
+    $ kind create cluster --config=./.github/config/acceptance_tests_kind_config.yaml
+    ```
+
+    KinD comes with a default Node image version that depends on the KinD version and thus might not be always the one you want to use. The above command can be extended with the `--image` option to spin up a particular Kubernetes version:
+
+    ```console
+    $ kind create cluster \
+      --config=./.github/config/acceptance_tests_kind_config.yaml \
+      --image kindest/node:v1.28.0@sha256:b7a4cad12c197af3ba43202d3efe03246b3f0793f162afb40a33c923952d5b31
+    ```
+
+    Refer to the KinD [releases](https://github.com/kubernetes-sigs/kind/releases) to get the right image.
+
+    From now on, we are going to assume that the Kubernetes configuration is stored in the `$HOME/.kube/config` file, and the current context is set to a newly created KinD cluster.
+
+    Once the Kubernetes cluster is up and running, we strongly advise you to run acceptance tests before making any changes to ensure they work with your setup. Please refer to the [Testing](#testing) section for more details.
 
-## Contributing to the provider
 
-### Contributing Resources
+## Making Changes
 
-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](https://kubernetes.io/docs/reference/#api-reference) for the appropriate version of Kubernetes.
+### Adding a New Resource
 
-### Development Environment
+This quick guide covers best practices for adding a new Resource. 
 
-If you wish to work on the provider, you'll first need [Go](http://www.golang.org) installed on your machine (version 1.9+ is *required*). You'll also need to correctly setup a [GOPATH](http://golang.org/doc/code.html#GOPATH), as well as adding `$GOPATH/bin` to your `$PATH`.
+1. Ensure all dependncies are installed.
+1. Add an SDK Client. 
+1. Add Resource Schema and define attributes [see Kubernetes Documentation](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs). A best and recommended practice is reuse constants from the Kuberentes packages as a default value in an attribute or within a validation function. 
+1. Scaffold an empty/new resource.
+1. Add Acceptance Tests(s) for the resource.
+1. Run Acceptance Tests(s) for this resource. 
+1. Add Documentation for this resource by editing the `.md.tmpl` file to include the appropriate [Data Fields](https://pkg.go.dev/text/template) and executing `tfplugindocs generate` command [see Terraform PluginDocs](https://github.com/hashicorp/terraform-plugin-docs#data-fields) then inspecting the corresponding `.md` file in the `/docs` to see all changes. The Data Fields that are currently apart of the templates are those for the Schema ({{ .SchemaMarkdown }}), Name ({{ .Name }}) and ({{ .Description }}).
+1. Execute `make docs-lint` and `make tests-lint` commands 
+1. Create a Pull Request for your changes. 
 
-To compile the provider, run `make build`. This will build the provider and put the provider binary in the `$GOPATH/bin` directory.
+### Adding a New Data Source
 
-```sh
-$ make build
-...
-$ $GOPATH/bin/terraform-provider-kubernetes
-...
+1. Ensure all dependncies are installed.
+1. Add an SDK Client. 
+1. Add Data Source Schema and define attributes [see Kubernetes Documentation](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs).
+A best and recommended practice is reuse constants from the Kuberentes packages as a default value in an attribute or within a validation function. 
+1. Scaffold an empty/new resource.
+1. Add Acceptance Tests(s) for the data source.
+1. Run Acceptance Tests(s) for this data source. 
+1. Add Documentation for this data source by editing the `.md.tmpl` file to include the appropriate [Data Fields](https://pkg.go.dev/text/template) and executing `tfplugindocs generate` command [see Terraform PluginDocs](https://github.com/hashicorp/terraform-plugin-docs#data-fields) then inspecting the corresponding `.md` file in the `/docs` to see all changes. The Data Fields that are currently apart of the templates are those for the Schema ({{ .SchemaMarkdown }}), Name ({{ .Name }}) and ({{ .Description }}).    
+1. Execute `make docs-lint` and `make tests-lint` commands 
+1. Create a Pull Request for your changes. 
+
+### Adding/Editing Documentation
+All Documentation is edited in the `.md.tmpl` file. Please note that the `tfplugindocs generate` command should be executed to ensure it is updated and reflected in the `.md` files. 
+
+## Testing
+
+The Kubernetes provider includes two types of tests: [unit](https://developer.hashicorp.com/terraform/plugin/sdkv2/testing/unit-testing) tests and [acceptance](https://developer.hashicorp.com/terraform/plugin/sdkv2/testing/acceptance-tests) tests.
+
+Before running any tests, make sure that the `KUBE_CONFIG_PATH` environment variable points to the Kubernetes configuration file:
+
+```console
+$ export KUBE_CONFIG_PATH=$HOME/.kube/config
 ```
 
-In order to test the provider, you can simply run `make test`.
+The following commands demonstrate how to run unit and acceptance tests respectively.
 
-```sh
-$ make test
+```console
+$ make test # unit tests
+$ make testacc TESTARGS="-run ^TestAcc" # acceptance tests
 ```
 
-In order to run the full suite of Acceptance tests, run `make testacc`.
+1. Run existing tests
+1. Write/Update tests
+1. Run tests with new changes
 
-*Note:* Acceptance tests create real resources, and often cost money to run.
+## Updating changelog
 
-```sh
-$ make testacc
-```
+A PR that is merged may or may not be added to the changelog. Not every change should be in the changelog since they don't affect users directly. Some instances of PRs that could be excluded are:
+
+- unit and acceptance tests fixes
+- minor documentation changes
+
+However, PRs of the following categories should be added to the appropriate section:
+
+* `FEATURES` 
+* `ENHANCEMENTS`
+* `MAJOR BUG FIXES`
+
+Please refer to our [ChangeLog Guide](../CHANGELOG_GUIDE.md).
+
+## Creating & Submiting a PR
 
-### Tests
+Please refer to this [guide](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork).
 
-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.