Add pre-commit hook for helm lint, update copyright, and update contr…

…ibution guide

.pre-commit-config.yaml

@@ -0,0 +1,5 @@
+repos:
+  - repo: https://github.com/gruntwork-io/pre-commit
+    sha: v0.0.5
+    hooks:
+      - id: helmlint

CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 Contributions to this Package are very welcome! We follow a fairly standard [pull request process](
 https://help.github.com/articles/about-pull-requests/) for contributions, subject to the following guidelines:
- 
+
 1. [File a GitHub issue](#file-a-github-issue)
 1. [Update the documentation](#update-the-documentation)
 1. [Update the tests](#update-the-tests)
@@ -13,24 +13,25 @@ https://help.github.com/articles/about-pull-requests/) for contributions, subjec
 ## File a GitHub issue
 
 Before starting any work, we recommend filing a GitHub issue in this repo. This is your chance to ask questions and
-get feedback from the maintainers and the community before you sink a lot of time into writing (possibly the wrong) 
+get feedback from the maintainers and the community before you sink a lot of time into writing (possibly the wrong)
 code. If there is anything you're unsure about, just ask!
 
 ## Update the documentation
 
-We recommend updating the documentation *before* updating any code (see [Readme Driven 
-Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html)). This ensures the documentation 
-stays up to date and allows you to think through the problem at a high level before you get lost in the weeds of 
+We recommend updating the documentation *before* updating any code (see [Readme Driven
+Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html)). This ensures the documentation
+stays up to date and allows you to think through the problem at a high level before you get lost in the weeds of
 coding.
 
 ## Update the tests
 
-We also recommend updating the automated tests *before* updating any code (see [Test Driven 
-Development](https://en.wikipedia.org/wiki/Test-driven_development)). That means you add or update a test case, 
-verify that it's failing with a clear error message, and *then* make the code changes to get that test to pass. This 
-ensures the tests stay up to date and verify all the functionality in this Module, including whatever new 
-functionality you're adding in your contribution. Check out the [tests](https://github.com/gruntwork-io/helm-kubernetes-services/tree/master/test) folder for instructions on running the 
-automated tests. 
+We also recommend updating the automated tests *before* updating any code (see [Test Driven
+Development](https://en.wikipedia.org/wiki/Test-driven_development)). That means you add or update a test case,
+verify that it's failing with a clear error message, and *then* make the code changes to get that test to pass. This
+ensures the tests stay up to date and verify all the functionality in this Module, including whatever new
+functionality you're adding in your contribution. Check out the
+[tests](https://github.com/gruntwork-io/helm-kubernetes-services/tree/master/test) folder for instructions on running
+the automated tests.
 
 ## Update the code
 
@@ -42,43 +43,34 @@ keep in mind two things:
 
 ### Backwards compatibility
 
-Please make every effort to avoid unnecessary backwards incompatible changes. With Terraform code, this means:
+Please make every effort to avoid unnecessary backwards incompatible changes. With Helm charts, this means:
 
 1. Do not delete, rename, or change the type of input variables.
-1. If you add an input variable, it should have a `default`.
+1. If you add an input variable, set a default in `values.yaml`.
 1. Do not delete, rename, or change the type of output variables.
-1. Do not delete or rename a module in the `modules` folder.
+1. Do not delete or rename a chart in the `charts` folder.
 
-If a backwards incompatible change cannot be avoided, please make sure to call that out when you submit a pull request, 
-explaining why the change is absolutely necessary. 
+If a backwards incompatible change cannot be avoided, please make sure to call that out when you submit a pull request,
+explaining why the change is absolutely necessary.
 
 ### Downtime
 
-Bear in mind that the Terraform code in this Module is used by real companies to run real infrastructure in 
-production, and certain types of changes could cause downtime. For example, consider the following:
-
-1. If you rename a resource (e.g. `aws_instance "foo"` -> `aws_instance "bar"`), Terraform will see that as deleting
-   the old resource and creating a new one.
-1. If you change certain attributes of a resource (e.g. the `name` of an `aws_elb`), the cloud provider (e.g. AWS) may
-   treat that as an instruction to delete the old resource and a create a new one. 
-
-Deleting certain types of resources (e.g. virtual servers, load balancers) can cause downtime, so when making code
-changes, think carefully about how to avoid that. For example, can you avoid downtime by using 
-[create_before_destroy](https://www.terraform.io/docs/configuration/resources.html#create_before_destroy)? Or via
-the `terraform state` command? If so, make sure to note this in our pull request. If downtime cannot be avoided, 
-please make sure to call that out when you submit a pull request. 
+Bear in mind that the Helm charts in this Module are used by real companies to run real infrastructure in
+production, and certain types of changes could cause downtime. If downtime cannot be avoided, please make sure to call
+that out when you submit a pull request.
 
 
 ### Formatting and pre-commit hooks
 
-You must run `terraform fmt` on the code before committing. You can configure your computer to do this automatically 
+You must run `helm lint` on the code before committing. You can configure your computer to do this automatically
 using pre-commit hooks managed using [pre-commit](http://pre-commit.com/):
 
 1. [Install pre-commit](http://pre-commit.com/#install). E.g.: `brew install pre-commit`.
 1. Install the hooks: `pre-commit install`.
+1. Make sure you have the helm client installed. See [the official docs](https://docs.helm.sh/using_helm/#install-helm)
+   for instructions.
 
-That's it! Now just write your code, and every time you commit, `terraform fmt` will be run on the files you're 
-committing.
+That's it! Now just write your code, and every time you commit, `helm lint` will be run on the charts that you modify.
 
 
 ## Create a pull request
@@ -89,11 +81,11 @@ to include the following:
 1. A description of the change, including a link to your GitHub issue.
 1. The output of your automated test run, preferably in a [GitHub Gist](https://gist.github.com/). We cannot run
    automated tests for pull requests automatically due to [security
-   concerns](https://circleci.com/docs/fork-pr-builds/#security-implications), so we need you to manually provide this 
+   concerns](https://circleci.com/docs/fork-pr-builds/#security-implications), so we need you to manually provide this
    test output so we can verify that everything is working.
 1. Any notes on backwards incompatibility or downtime.
 
-## Merge and release   
+## Merge and release
 
 The maintainers for this repo will review your code and provide feedback. If everything looks good, they will merge the
 code and release a new version, which you'll be able to find in the [releases page](../../releases).

GRUNTWORK_PHILOSOPHY.md

@@ -17,11 +17,11 @@ resilient, fault tolerant, and scalable.
 A Module is a reusable, tested, documented, configurable, best-practices definition of a single piece of Infrastructure
 (e.g., Docker cluster, VPC, Jenkins, Consul), written using a combination of [Terraform](https://www.terraform.io/), Go,
 and Bash. A module contains a set of automated tests, documentation, and examples that have been proven in production,
-providing the underlying infrastructure for [Gruntwork's customers](https://www.gruntwork.io/customers).  
+providing the underlying infrastructure for [Gruntwork's customers](https://www.gruntwork.io/customers).
 
 Instead of figuring out the details of how to run a piece of infrastructure from scratch, you can reuse existing code
 that has been proven in production. And instead of maintaining all that infrastructure code yourself, you can leverage
-the work of the community to pick up infrastructure improvements through a version number bump.  
+the work of the community to pick up infrastructure improvements through a version number bump.
 
 
 ## What is a Submodule?

LICENSE

@@ -186,7 +186,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright [yyyy] [name of copyright owner]
+   Copyright 2019 Gruntwork, Inc
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

README.md

@@ -142,4 +142,4 @@ MINOR, and PATCH versions on each release to indicate any incompatibilities.
 
 Please see [LICENSE](/LICENSE) for how the code in this repo is licensed.
 
-Copyright © 2018 Gruntwork, Inc.
+Copyright © 2019 Gruntwork, Inc.