Thanks for your interest in improving this project! Before we get technical, make sure you have reviewed the code of conduct, Developer Certificate of Origin, and OWNERS files. Code will be licensed according to LICENSE.
When creating a pull request, please refer to an open issue. If there is no issue open for the pull request you are creating, please create one. Frequently, pull requests may be merged or closed while the underlying issue being addressed is not fully addressed. Issues are a place to discuss the problem in need of a solution. Pull requests are a place to discuss an implementation of one particular answer to that problem. A pull request may not address all (or any) of the problems expressed in the issue, so it is important to track these separately.
All public functions and variables should include at least a short description of the functionality they provide. Comments should be formatted according to https://golang.org/doc/effective_go.html#commentary.
Documentation at https://pkg.go.dev/github.com/phoenixnap/k8s-cloud-provider-bmc will be generated from these comments.
Although the PhoenixNAP CCM is intended more as a standalone runtime container than a library, following the generally accepted golang standards will make it easier to maintain this project, and easier for others to contribute.
golangci-lint is used to verify that the style of the code remains consistent.
make lint can be used to verify style before creating a pull request.
Before committing, it's a good idea to run goimports -w ..
(goimports)
The Makefile contains the targets to build, lint, vet and test:
make build lint vet testThese normally will be run using your locally installed golang tools. If you do not have them
installed, or do not want to use local ones for any other reason, you can run it in a docker
image by setting the var DOCKERBUILD=true:
make build lint vet test DOCKERBUILD=trueIf you want to see HTTP requests, set the environment variable PNAP_DEBUG=true, for example:
PNAP_DEBUG=true make testAll CI/CD is performed via github actions, see the files in .github/workflows/.