@@ -103,22 +103,38 @@ Because it enables us to do something really cool, like dynamically override con
You can test your *local changes* and manipulate the staging environments by using the helm-charts repo. Create your branch, make your changes and then, inside your helm-charts repository branch, run:
Then you must restart the pod by finding its name and deleting it.
Adding a new value requires a bit more leg work. Create a new branch in helm charts and add your values to configMap.yaml and values.yaml. Then, you can:
kubectl get pods | grep {your.staging.site.subdomain}
helm del --purge {your.staging.site.subdomain}
```
We don't need to specify a set value here because the value doesn't exist. However, once you set it, it will continue to be inherited from the last release becase of --reuse-values and you'll need to update it with set.
If you hose anything, you can always re-run the pipeline which will rebuild the pods with the latest configuration in master and start over.
## Interacting with the Staging environment
You can get access to the pods by using **kubectl**. Note, pods are read-only and ephemeral, so you can't go hacking things on the container.
Get a list of all pods
```console
kubectl get pods
```
Shell into a pod using the name from ```get pods``` (read only)
```console
kubectl exec -it {your.staging.site.subdomain}-{pod.type}-{kubernetes-suffix} sh