Skip to content

Commit 0ca6f8a

Browse files
committed
Add readme to testing chart
1 parent 77ec09a commit 0ca6f8a

File tree

1 file changed

+29
-0
lines changed

1 file changed

+29
-0
lines changed

charts/kubectl-test/README.md

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
# Kubectl Test Chart
2+
This chart facilitates testing of RC versions of `rancher/kuberlr-kubectl` image.
3+
4+
Specifically this allows us to create, test and QA an RC version of the image without needing to involve dependent charts.
5+
The goal being that we shouldn't need to "mix processes" and utilize another project for testing this project.
6+
7+
## What does this test for?
8+
To correctly provide a validation w/o using consuming charts, we need to ensure this chart does the same type of stuff.
9+
Additionally, we should ensure that when it does those actions it will create loud and obvious errors when failure happens.
10+
11+
Some examples of scenarios this should cover:
12+
- Post upgrade jobs (like BRO, Monitoring),
13+
- Creating a `ServiceAccount` (with appropriate bindings) and using that for upgrade task (like BRO),
14+
- Storing upgrade scripts in a `ConfigMap` and then running them on upgrade (like Monitoring)
15+
16+
As we find more specific use-cases within Rancher that existing scenarios do not cover, we should create issues to track adding new tests.
17+
18+
## How does (or will) this work?
19+
20+
This chart will be packaged as a release artifact with each GitHub release.
21+
In turn every tag going forward will have a direct 1:1 chart that can be used for testing and QA of that tag.
22+
23+
Eng will create a new RC and upon success of the action, they will inform QA (via the related issue) that the RC is ready for testing.
24+
Once QA picks up the issue for testing they will fetch the debug/QA chart from the release and install via CLI.
25+
Then they will subsequently "upgrade" to the same version to trigger any upgrade specific jobs.
26+
27+
After each phase QA will be able to verify the resources and jobs in the testing namespace.
28+
As long as they do not observe any errors - just as they would expect for a production chart - the RC has passed.
29+
Then once the `rancher/kuberlr-kubectl` tag has been un-RC'd any consuming charts can update to the new stable tag.

0 commit comments

Comments
 (0)