github/kured
1
0
Fork 0
mirror of https://github.com/kubereboot/kured.git synced 2026-08-28 05:47:23 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update contributor docs

Browse Source 
- Explain kured code structure
	- Update links, as some docs have moved
	- Readability and fix typos

Signed-off-by: Daniel Holbach <daniel.holbach@gmail.com>
This commit is contained in:
Daniel Holbach
2024-08-05 20:48:05 +02:00
parent 58091f6145
commit d51c1fb683
1 changed files with 30 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CONTRIBUTING.md
+30 -20
View File
@@ -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 <https://github.com/kubereboot>. To find t
| <https://github.com/kubereboot/charts> | Helm chart |
| <https://github.com/kubereboot/website> | 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-<version>.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 <https://github.com/kubereboot/charts> 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 <k8s-release>
@@ -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-<k8s-version>.yaml
@@ -208,8 +218,8 @@ kind create cluster --config .github/kind-cluster-<k8s-version>.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-<release>-dockerhub.yaml` file.
Please describe what's new and noteworthy in the release notes, list the PRs