Apply folder/category structure of docs.helm.sh

- moves Docs files from root /docs into subfolders
- adds a using-helm folder (6 docs)
- adds a architecture folder (1 doc)
- adds a developing-charts folder (8 docs)
- adds a glossary folder (1 doc)
- adds a history folder (1 doc)
- adds a related folder (1 doc)
- renames the helm folder to helm-commands

docs/chart-best-practices/index.md

@@ -17,4 +17,3 @@ may find that their internal interests override our suggestions here.
 - Kubernetes Resources:
 	- [Pods and Pod Specs](pods.md): See the best practices for working with pod specifications.
 	- [Third Party Resources](third_party_resources.md): Third Party Resources (TPRs) have their own associated best practices.
-

docs/chart-best-practices/labels.md

@@ -47,8 +47,3 @@ release | REC | This should be the `{{ .Release.Name }}`.
 chart | REC | This should be the chart name and version: `{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}`.
 app | OPT | This should be the app name, reflecting the entire app. Often the chart's `{{ .Chart.Name }}` is used for this. This is used by many Kubernetes manifests, and is not Helm-specific.
 component | OPT | This is a common label for marking the different roles that pieces may play in an application. For example, `component: frontend`
-
-
-
-
-

docs/chart-best-practices/pods.md

@@ -73,5 +73,3 @@ the pod.
 But this is even more important for sets like Deployment.
 Without this, the _entire_ set of labels is used to select matching pods, and
 this will break if you use labels that change, like version or release date.
-
-

docs/chart-best-practices/templates.md

@@ -89,7 +89,7 @@ Blocks (such as control structures) may be indented to indicate flow of the temp
 ```
 {{ if $foo -}}
   {{- with .Bar }}Hello{{ end -}}
-{{- end -}} 
+{{- end -}}
 ```
 
 However, since YAML is a whitespace-oriented language, it is often not possible for code indentation to follow that convention.
@@ -196,7 +196,7 @@ readable than other YAML representations.
 For example, this YAML is closer to the normal YAML method of expressing lists:
 
 ```yaml
-arguments: 
+arguments:
   - "--dirname"
   - "/foo"
 ```

docs/chart-template-guide/accessing_files.md

@@ -124,7 +124,7 @@ the returned object.
 For example, imagine the directory structure:
 
 ```
-foo/: 
+foo/:
   foo.txt foo.yaml
 
 bar/:
@@ -222,4 +222,3 @@ data:
 Currently, there is no way to pass files external to the chart during `helm install`. So if you are asking users to supply data, it must be loaded using `helm install -f` or `helm install --set`.
 
 This discussion wraps up our dive into the tools and techniques for writing Helm templates. In the next section we will see how you can use one special file, `templates/NOTES.txt`, to send post-installation instructions to the users of your chart.
-

docs/chart-template-guide/builtin_objects.md

@@ -49,4 +49,3 @@ In the previous section, we use `{{.Release.Name}}` to insert the name of a rele
 The values are available to any top-level template. As we will see later, this does not necessarily mean that they will be available _everywhere_.
 
 The built-in values always begin with a capital letter. This is in keeping with Go's naming convention. When you create your own names, you are free to use a convention that suits your team. Some teams, like the [Kubernetes Charts](https://github.com/kubernetes/charts) team, choose to use only initial lower case letters in order to distinguish local names from those built-in. In this guide, we follow that convention.
-

docs/chart-template-guide/control_structures.md

@@ -115,7 +115,7 @@ CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart
 Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key
 ```
 
-What happened? We generated incorrect YAML because of the whitespacing above. 
+What happened? We generated incorrect YAML because of the whitespacing above.
 
 ```yaml
 # Source: mychart/templates/configmap.yaml

docs/developer-guide/developers.md

@@ -139,7 +139,7 @@ The code for the Helm project is organized as follows:
 - The individual programs are located in `cmd/`. Code inside of `cmd/`
   is not designed for library re-use.
 - Shared libraries are stored in `pkg/`.
-- The raw ProtoBuf files are stored in `_proto/hapi` (where `hapi` stands for 
+- The raw ProtoBuf files are stored in `_proto/hapi` (where `hapi` stands for
   the Helm Application Programming Interface).
 - The Go files generated from the `proto` definitions are stored in `pkg/proto`.
 - The `scripts/` directory contains a number of utility scripts. Most of these

docs/developing-charts/charts.md

@@ -323,11 +323,11 @@ tags:
 
 In the above example all charts with the tag `front-end` would be disabled but since the
 `subchart1.enabled` path evaluates to 'true' in the parent's values, the condition will override the
-`front-end` tag and `subchart1` will be enabled.  
+`front-end` tag and `subchart1` will be enabled.
 
 Since `subchart2` is tagged with `back-end` and that tag evaluates to `true`, `subchart2` will be
 enabled. Also note that although `subchart2` has a condition specified in `requirements.yaml`, there
-is no corresponding path and value in the parent's values so that condition has no effect.  
+is no corresponding path and value in the parent's values so that condition has no effect.
 
 ##### Using the CLI with Tags and Conditions
 
@@ -350,19 +350,19 @@ helm install --set tags.front-end=true --set subchart2.enabled=false
 
 #### Importing Child Values via requirements.yaml
 
-In some cases it is desirable to allow a child chart's values to propagate to the parent chart and be 
-shared as common defaults. An additional benefit of using the `exports` format is that it will enable future 
+In some cases it is desirable to allow a child chart's values to propagate to the parent chart and be
+shared as common defaults. An additional benefit of using the `exports` format is that it will enable future
 tooling to introspect user-settable values.
 
-The keys containing the values to be imported can be specified in the parent chart's `requirements.yaml` file 
-using a YAML list. Each item in the list is a key which is imported from the child chart's `exports` field. 
+The keys containing the values to be imported can be specified in the parent chart's `requirements.yaml` file
+using a YAML list. Each item in the list is a key which is imported from the child chart's `exports` field.
 
 To import values not contained in the `exports` key, use the [child/parent](#using-the-child/parent-format) format.
 Examples of both formats are described below.
 
 ##### Using the exports format
 
-If a child chart's `values.yaml` file contains an `exports` field at the root, its contents may be imported 
+If a child chart's `values.yaml` file contains an `exports` field at the root, its contents may be imported
 directly into the parent's values by specifying the keys to import as in the example below:
 
 ```yaml
@@ -379,8 +379,8 @@ exports:
     myint: 99
 ```
 
-Since we are specifying the key `data` in our import list, Helm looks in the the `exports` field of the child 
-chart for `data` key and imports its contents. 
+Since we are specifying the key `data` in our import list, Helm looks in the the `exports` field of the child
+chart for `data` key and imports its contents.
 
 The final parent values would contain our exported field:
 
@@ -391,16 +391,16 @@ myint: 99
 
 ```
 
-Please note the parent key `data` is not contained in the parent's final values. If you need to specify the 
-parent key, use the 'child/parent' format. 
+Please note the parent key `data` is not contained in the parent's final values. If you need to specify the
+parent key, use the 'child/parent' format.
 
 ##### Using the child/parent format
 
-To access values that are not contained in the `exports` key of the child chart's values, you will need to 
-specify the source key of the values to be imported (`child`) and the destination path in the parent chart's 
+To access values that are not contained in the `exports` key of the child chart's values, you will need to
+specify the source key of the values to be imported (`child`) and the destination path in the parent chart's
 values (`parent`).
 
-The `import-values` in the example below instructs Helm to take any values found at `child:` path and copy them 
+The `import-values` in the example below instructs Helm to take any values found at `child:` path and copy them
 to the parent's values at the path specified in `parent:`
 
 ```yaml
@@ -415,7 +415,7 @@ dependencies:
         parent: myimports
 ```
 In the above example, values found at `default.data` in the subchart1's values will be imported
-to the `myimports` key in the parent chart's values as detailed below: 
+to the `myimports` key in the parent chart's values as detailed below:
 
 ```yaml
 # parent's values.yaml file
@@ -424,7 +424,7 @@ myimports:
   myint: 0
   mybool: false
   mystring: "helm rocks!"
-  
+
 ```
 ```yaml
 # subchart1's values.yaml file
@@ -433,7 +433,7 @@ default:
   data:
     myint: 999
     mybool: true
-    
+
 ```
 The parent chart's resulting values would be:
 

docs/developing-charts/charts_hooks.md

@@ -80,7 +80,7 @@ hooks, the lifecycle is altered like this:
 5. Tiller sorts hooks by weight (assigning a weight of 0 by default) and by name for those hooks with the same weight in ascending order.
 6. Tiller then loads the hook with the lowest weight first (negative to positive)
 7. Tiller waits until the hook is "Ready"
-8. Tiller loads the resulting resources into Kubernetes. Note that if the `--wait` 
+8. Tiller loads the resulting resources into Kubernetes. Note that if the `--wait`
 flag is set, Tiller will wait until all resources are in a ready state
 and will not run the `post-install` hook until they are ready.
 9. Tiller executes the `post-install` hook (loading hook resources)
@@ -187,5 +187,4 @@ deterministic executing order. Weights are defined using the following annotatio
 
 Hook weights can be positive or negative numbers but must be represented as
 strings. When Tiller starts the execution cycle of hooks of a particular Kind it
-will sort those hooks in ascending order. 
-
+will sort those hooks in ascending order.

docs/developing-charts/charts_tips_and_tricks.md

@@ -124,7 +124,7 @@ with the old configuration resulting in an inconsistent deployment.
 
 The `sha256sum` function can be used together with the `include`
 function to ensure a deployments template section is updated if another
-spec changes: 
+spec changes:
 
 ```yaml
 kind: Deployment

docs/glossary/glossary.md

@@ -179,5 +179,3 @@ These exposed variables are called _values_ in Helm parlance.
 Values can be set during `helm install` and `helm upgrade` operations,
 either by passing them in directly, or by uploading a `values.yaml`
 file.
-
-

docs/index.md

@@ -1,35 +0,0 @@
-# Helm Documentation
-
-- [Quick Start](quickstart.md) - Read me first!
-- [Installing Helm](install.md) - Install Helm and Tiller
-  - [Kubernetes Distribution Notes](kubernetes_distros.md)
-  - [Frequently Asked Questions](install_faq.md)
-- [Using Helm](using_helm.md) - Learn the Helm tools
-  - [Plugins](plugins.md)
-- [Developing Charts](charts.md) - An introduction to chart development
-	- [Chart Lifecycle Hooks](charts_hooks.md)
-	- [Chart Tips and Tricks](charts_tips_and_tricks.md)
-	- [Chart Repository Guide](chart_repository.md)
-	- [Syncing your Chart Repository](chart_repository_sync_example.md)
-	- [Signing Charts](provenance.md)
-	- [Writing Tests for Charts](chart_tests.md)
-- [Chart Template Developer's Guide](chart_template_guide/index.md) - Master Helm templates
-  - [Getting Started with Templates](chart_template_guide/getting_started.md)
-  - [Built-in Objects](chart_template_guide/builtin_objects.md)
-  - [Values Files](chart_template_guide/values_files.md)
-  - [Functions and Pipelines](chart_template_guide/functions_and_pipelines.md)
-  - [Flow Control (if/else, with, range, whitespace management)](chart_template_guide/control_structures.md)
-  - [Variables](chart_template_guide/variables.md)
-  - [Named Templates (Partials)](chart_template_guide/named_templates.md)
-  - [Accessing Files Inside Templates](chart_template_guide/accessing_files.md)
-  - [Creating a NOTES.txt File](chart_template_guide/notes_files.md)
-  - [Subcharts and Global Values](chart_template_guide/subcharts_and_globals.md)
-  - [Debugging Templates](chart_template_guide/debugging.md)
-  - [Wrapping Up](chart_template_guide/wrapping_up.md)
-  - [Appendix A: YAML Techniques](chart_template_guide/yaml_techniques.md)
-  - [Appendix B: Go Data Types](chart_template_guide/data_types.md)
-- [Related Projects](related.md) - More Helm tools, articles, and plugins
-- [Architecture](architecture.md) - Overview of the Helm/Tiller design
-- [Developers](developers.md) - About the developers
-- [History](history.md) - A brief history of the project
-- [Glossary](glossary.md) - Decode the Helm vocabulary