From d51c1fb683ef939183ff446771da4ff6d16d36e4 Mon Sep 17 00:00:00 2001 From: Daniel Holbach Date: Mon, 5 Aug 2024 20:48:05 +0200 Subject: [PATCH] Update contributor docs - Explain kured code structure - Update links, as some docs have moved - Readability and fix typos Signed-off-by: Daniel Holbach --- CONTRIBUTING.md | 50 +++++++++++++++++++++++++++++-------------------- 1 file changed, 30 insertions(+), 20 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 73a7015..bebfd2c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -5,13 +5,13 @@ Slack][slack], reporting or triaging [issues][issues] or contributing code to `kured`. In any case, it will make sense to familiarise yourself with the main -[README][readme] to understand the different features and options, which is -helpful for testing. The "building" section in particular makes sense if -you are planning to contribute code. +[documentation][documentation] to understand the different features and +options, which is helpful for testing. The "building" section in +particular makes sense if you are planning to contribute code. [slack]: README.md#getting-help [issues]: https://github.com/kubereboot/kured/issues -[readme]: README.md +[documentation]: https://kured.dev/docs ## Certificate of Origin @@ -41,6 +41,15 @@ All Kured repositories are kept under . To find t | | Helm chart | | | website and documentation | +### Kured code + +- Kured's main code can be found in the [`cmd`](cmd) and [`pkg`](pkg) directories +- Its smoke tests are in the [`tests`](tests) directory +- We use [GoReleaser to build](.goreleaser.yml). +- Every PR and tagged release is tested by [Kind in GitHub workflows](.github/workflows). + +As a project, we try to follow all the official and obvious standards. + ## Regular development activities ### Prepare environment @@ -70,12 +79,12 @@ Please update our `.github/workflows` with the new k8s images, starting by the creation of a `.github/kind-cluster-.yaml`, then updating our workflows with the new versions. -Once you updated everything, make sure you update the support matrix on -the main [README][readme] as well. +Once you updated everything, make sure you update the support matrix in +the [installation docs](https://kured.dev/docs/installation/) as well. ### Updating other dependencies -Dependabot proposes changes in our go.mod/go.sum. +Dependabot proposes changes in our `go.mod`/`go.sum`. Some of those changes are covered by CI testing, some are not. Please make sure to test those not covered by CI (mostly the integration @@ -87,7 +96,7 @@ We run periodic jobs (see also Automated testing section of this documentation). Those should be monitored for failures. If a failure happen in periodics, something terribly wrong must have happened -(or github is failing at the creation of a kind cluster). Please monitor those +(or GitHub is failing at the creation of a kind cluster). Please monitor those failures carefully. ### Introducing new features @@ -107,23 +116,24 @@ This also means that when you expose a new feature, you should create another PR for your changes in to make your feature available at the next kured version for helm users. -In the charts PR, you can directly bump the appVersion to the next minor version +In the charts PR, you can directly bump the `appVersion` to the next minor version (you are introducing a new feature, which requires a bump of the minor number. -For example, if current appVersion is 1.6.x, make sure you update your appVersion -to 1.7.0). It allows us to have an easy view of what we land each release. +For example, if current `appVersion` is `1.6.x`, make sure you update your `appVersion` +to `1.7.0`). It allows us to have an easy view of what we land each release. Do not hesitate to increase the test coverage for your feature, whether it's unit -testing to full functional testing (even using helm charts) +testing to full functional testing (even using helm charts). ### Increasing test coverage We are welcoming any change to increase our test coverage. -See also our github issues for the label `testing`. +See also our GitHub issues for the label +[`testing`](https://github.com/kubereboot/kured/labels/testing). ## Automated testing -Our CI is covered by github actions. -You can see their contents in .github/workflows. +Our CI is covered by GitHub actions. +You can see their contents in `.github/workflows`. We currently run: @@ -160,7 +170,7 @@ Please run `make test`. You should have `golint` installed. A test-run with `minikube` could look like this: -```console +```cli # start minikube minikube start --driver=kvm2 --kubernetes-version @@ -192,7 +202,7 @@ Then you can check for the lock release. A test-run with `kind` could look like this: -```console +```cli # create kind cluster kind create cluster --config .github/kind-cluster-.yaml @@ -208,8 +218,8 @@ kind create cluster --config .github/kind-cluster-.yaml ### Prepare Documentation -Check that [compatibility matrix](https://kured.dev/docs/installation/) is updated -to the new version you want to release. +Ensure the [compatibility matrix](https://kured.dev/docs/installation/) is +updated to the new version you want to release. ### Create a tag on the repo @@ -231,7 +241,7 @@ cat kured-ds.yaml >> "$MANIFEST" ### Publish release artifacts -Now you can head to the Github UI, use the version number as tag and upload the +Now you can head to the GitHub UI, use the version number as tag and upload the `kured--dockerhub.yaml` file. Please describe what's new and noteworthy in the release notes, list the PRs