Commit ba54b199 authored by Jean-Philippe Evrard's avatar Jean-Philippe Evrard
Browse files

Clarify development process

Without this, it's a little bit hard to grasp how things
are interconnected. This should clarify things.
parent 679f45c3
......@@ -31,8 +31,8 @@ the main [README][readme] as well.
Before `kured` is released, we want to make sure it still works fine on the
previous, current and next minor version of Kubernetes (with respect to the
embedded `client-go` & `kubectl`). For local testing e.g. `minikube` can be
sufficient.
embedded `client-go` & `kubectl`). For local testing e.g. `minikube` or
`kind` can be sufficient.
Deploy kured in your test scenario, make sure you pass the right `image`,
update the e.g. `period` and `reboot-days` options, so you get immediate
......@@ -82,36 +82,74 @@ If all the tests ran well, kured maintainers can reach out to the Weaveworks
team to get an upcoming `kured` release tested in the Dev environment for
real life testing.
### Testing with `kind`
A test-run with `kind` could look like this:
```console
# create kind cluster
kind create cluster --config .github/kind-cluster.yaml
# create reboot required files on pre-defined kind nodes
./tests/create-reboot-sentinels.sh
# check if reboot is working fine
./tests/kind/follow-coordinated-reboot.sh
```
## Publishing a new kured release
### Prepare Documentation
Check that `README.md` has an updated compatibility matrix and that the
url in the `kubectl` incantation (under "Installation") is updated to the
new version you want to release.
### Create a tag on the repo and publish the image
Before going further, we should freeze the code for a release, by
tagging the code, and publishing its immutable artifact: the kured
docker image.
```sh
make DH_ORG="weaveworks" VERSION="1.3.0" image
```
Then docker push the image. In the future, that might be automatically
done when creating a tag on the repository, with the help of github
actions.
### Prepare Helm chart
You should also check that the helm chart has been updated before issuing
a release. You can bump the helm chart with the latest image
tag by running:
```sh
make DH_ORG="weaveworks" VERSION="1.3.0" helm-chart
```
Finally bump the `version` in `charts/kured/Chart.yaml` (following
the versioning rules) and you should be all set.
### Create the combined manifest
Now create the `kured-<release>-dockerhub.yaml` for e.g. `1.3.0`:
```sh
VERSION=1.3.0
MANIFEST="kured-$VERSION-dockerhub.yaml"
make DH_ORG="weaveworks" VERSION="${VERSION}" manifest
cat kured-rbac.yaml > "$MANIFEST"
cat kured-ds.yaml >> "$MANIFEST"
sed -i "s#docker.io/weaveworks/kured#docker.io/weaveworks/kured:$VERSION#g" "$MANIFEST"
```
To make this available for our Helm users, please make sure you update the
image version in
- `charts/kured/values.yaml` (`tag`),
- `charts/kured/Chart.yaml` (`appVersion`) and
- `charts/kured/README.md` (`image.tag`) as well.
Finally bump the `version` in `charts/kured/Chart.yaml` and you should be
all set.
### Publish release artifacts
Now you can head to the Github UI, use the version number as tag and upload the
`kured-<release>-dockerhub.yaml` file.
### Release notes
The creation of the release will publish the helm chart (thanks to github actions).
Please describe what's new and noteworthy in the release notes, list the PRs
that landed and give a shout-out to everyone who contributed.
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment