Add documentation about helmfile-fetch and StateValues alias (#1746)

Ref #1743, #1744, #1734

README.md

@@ -475,6 +475,7 @@ COMMANDS:
    test          test releases from state file (helm test)
    build         output compiled helmfile state(s) as YAML
    list          list releases defined in state file
+   fetch         fetch charts from state file
    version       Show the version for Helmfile.
    help, h       Shows a list of commands or help for one command
 
@@ -572,6 +573,11 @@ Use `--cleanup` to delete pods upon completion.
 
 The `helmfile lint` sub-command runs a `helm lint` across all of the charts/releases defined in the manifest. Non local charts will be fetched into a temporary folder which will be deleted once the task is completed.
 
+### fetch
+
+The `helmfile fetch` sub-command downloads or copies local charts to a local directory for debug purpose. The local directory
+must be specified with `--output-dir`.
+
 ## Paths Overview
 
 Using manifest files in conjunction with command line argument can be a bit confusing.

docs/writing-helmfile.md

@@ -2,6 +2,23 @@
 
 This guide covers the Helmfile’s considered patterns for writing advanced helmfiles. It focuses on how helmfile should be structured and executed.
 
+## Helmfile .Values vs Helm .Values
+
+Templating engine of Helmfile uses the same pipeline name `.Values` as Helm, so in some use-cases `.Vaues` of Helmfile and
+Helm can be seen in the same file. To distinguish these two kinds of `.Values`, Helmfile provides an alias `.StateValues`
+for its `.Values`.
+
+```
+app:
+  project: {{.Environmont.Name}}-{{.StateValues.project}} # Same as {{.Environmont.Name}}-{{.Values.project}}
+
+{{`
+extraEnvVars:
+- name: APP_PROJECT
+  value: {{.Values.app.project}}
+`}}
+```
+
 ## Missing keys and Default values
 
 helmfile tries its best to inform users for noticing potential mistakes.
@@ -314,7 +331,7 @@ helmDefaults:
   force: true
 ```
 
-Each go template is rendered in the context where `.Values` is inherited from the previous part. 
+Each go template is rendered in the context where `.Values` is inherited from the previous part.
 
 So in `mydefaults.yaml.gotmpl`, both `.Values.kubeContext` and `.Values.wait` are valid as they do exist in the environment values inherited from the previous part(=the first part) of your `helmfile.yaml.gotmpl`, and therefore the template is rendered to: