Skip to content

Latest commit

 

History

History
63 lines (38 loc) · 3.52 KB

CONTIBUTING.md

File metadata and controls

63 lines (38 loc) · 3.52 KB
Raw

Contributing

All commits should be signed using a key attached to your GitHub profile before creating a PR.

When creating a pull request, have a clear summary of what the change does and why the change is useful. As an example of an acceptable PR message:

This pull request adds support for Chia Wallets. This would be useful for writing 3rd party apps to be deployed to kubernetes that need to communicate to a Chia wallet's RPCs.

API Contributions

These rules/guidelines are meant to help keep a well-defined style for accomplishing controller logic.

  1. Optional API fields should always include omitempty as an option in the json tag. ex. json:"image,omitempty"
  2. Optional API fields may use pointers, but don't always need to. Take an optional bool for example, you may need to decide whether it's important to distinguish between true, false, and unspecified values. If you need to distinguish for unspecified, use a pointer. If the behavior for that field should be the zero value (false) if unspecified, don't use a pointer.
  3. Fields that are autogenerated by kubebuilder should be left as-is and these rules do not apply to them.

Adding a new API and Controller

You will need Golang, Make, and Kubebuilder CLI. See the Kubebuilder book for installing the CLI.

You can then create a new API and controller with kubebuilder create api --group k8s --version v1 --kind ChiaSomething Change ChiaSomething to your desired Kind; for a harvester, the name is ChiaHarvester. When you enter the command, it will ask you if you want to create the resource and the controller, type y for both.

Kubebuilder scaffolds a lot of files for us, but its defaults are a bit undesirable. There are multiple edits we will make besides implementing the API and controller logic that are described below:

  • In config/default/kustomization.yaml in the resources block, make sure the line - ../crd is commented. Kubebuilder CLI will have uncommented it.

  • In config/samples the name of the sample kubebuilder created should be changed to the Kind of the controller resource, such as chiasomething.yaml. Then fill it out with a basic working example of the Kind's usage.

  • In api/v1 edit the API types to match the needs of the API. Lean on the other API types for examples.

  • In internal/metrics make some new metric counters for the new Kind you created.

  • In internal/controller two files were created for the controller and controller's test. I usually find it simpler to delete these, and copy one of the existing controller directories and start editing that one. All the existing controllers are contained in their own packages in this directory, a pretty simple example would be ChiaWallet. Each of their tests are just contained in the internal/controller directory though.

  • In cmd/main.go we previously moved the reconciler function for the controller to its own directory, so we need to change where the reconciler function is here.

  • Run make to re-generate many of the manifests in the config/ directory. You will need to do this every time you change the API struct types.

  • Run make test often to check the test suite for issues.

Local testing

To test your changes, especially if you wrote accompanying tests for your changes:

make test

When you make a pull request, the repository will also be linted. To see the results of the linter test locally:

make lint

Some linter test failures can be automatically resolved:

make lint-fix