Skip to content
GitLab
Explore
Projects
Groups
Topics
Snippets
Projects
Groups
Topics
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
Menu
1105 Внедрение механизмов обеспечения безопасности цепочки поставки программных проектов
Legacy
scanned-projects
helm
Commits
f18121f3
Commit
f18121f3
authored
9 years ago
by
Seth Goings
Browse files
Options
Download
Patches
Plain Diff
docs: add test architecture design doc draft
parent
3cbe6ea2
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
docs/test-architecture.md
+59
-0
docs/test-architecture.md
with
59 additions
and
0 deletions
+59
-0
docs/test-architecture.md
0 → 100644
+
59
−
0
View file @
f18121f3
Testing via Helm
================
Problem Summary
---------------
Currently in helm/charts we have a simple way of health-checking charts which
checks that all pods in the chart reach "Running" state on a running Kubernetes
cluster. In order to build a system that holds chart quality at the forefront,
we need to introduce an easy way to create and run potentially more complex
application-centric tests.
Proposed Solution
-----------------
#### User Experience
```
# helm/dm UX for installing charts stays the same
# addition to UX giving easy-to-run tests:
helm test deis
```
#### Helm's new `test` Command
This command uses test logic located in
`<chart name>/tests/`
to ensure that
the chart is operating as intended in an end to end or system test sort of
fashion.
The command is fairly simple - all it does is load a set of charts into a
Kubernetes cluster (might be the same or different as the deployed chart).
What usually makes sense to have is a one-off pod that runs to completion and
exits with a certain exit code: non-zero signifying failure or zero signifying
success. The pod is not automatically restarted so that humans or automated
tools can inspect the results which might be a log, test artifact, or something
else.
`helm test`
should therefore be able to be rerun the tests over and over and
not be hindered by an existing similarly-named set of pods, rcs, or services.
By forcing tests to also be containerized and Kubernetes-ready we have the
benefit of having a single and easily understandable entry point - it's just
another set of Kubernetes components.
#### Modifications to Chart Structure
```
ROOT/
Chart.yaml
LICENSE
README.md
...
tests/
Chart.yaml
templates/
some.yaml
some.jinja
some.jinja.schema
```
This diff is collapsed.
Click to expand it.
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment
Menu
Explore
Projects
Groups
Topics
Snippets