diff --git a/terraform-google-{{cookiecutter.module_name}}/CONTRIBUTING.md b/terraform-google-{{cookiecutter.module_name}}/CONTRIBUTING.md index f321362..fc745e9 100644 --- a/terraform-google-{{cookiecutter.module_name}}/CONTRIBUTING.md +++ b/terraform-google-{{cookiecutter.module_name}}/CONTRIBUTING.md @@ -1,8 +1,29 @@ # Contributing -This document provides guidelines for contributing to the module. +We'd love to accept your patches and contributions to this project. There are +just a few small guidelines you need to follow. -## Dependencies +## Contributor License Agreement + +Contributions to this project must be accompanied by a Contributor License +Agreement (CLA). You (or your employer) retain the copyright to your +contribution; this simply gives us permission to use and redistribute your +contributions as part of the project. Head over to + to see your current agreements on file or +to sign a new one. + +You generally only need to submit a CLA once, so if you've already submitted one +(even if it was for a different project), you probably don't need to do it +again. + +## Code Reviews + +All submissions, including submissions by project members, require review. We +use GitHub pull requests for this purpose. Consult +[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more +information on using pull requests. + +## Development The following dependencies must be installed on the development system: @@ -10,18 +31,18 @@ The following dependencies must be installed on the development system: - [Google Cloud SDK][google-cloud-sdk] - [make] -## Generating Documentation for Inputs and Outputs +### Generating Documentation for Inputs and Outputs The Inputs and Outputs tables in the READMEs of the root module, submodules, and example modules are automatically generated based on the `variables` and `outputs` of the respective modules. These tables must be refreshed if the module interfaces are changed. -### Execution +#### Execution Run `make generate_docs` to generate new Inputs and Outputs tables. -## Integration Testing +### Integration Testing Integration tests are used to verify the behaviour of the root module, submodules, and example modules. Additions, changes, and fixes should @@ -35,7 +56,7 @@ The general strategy for these tests is to verify the behaviour of the [example modules](./examples/), thus ensuring that the root module, submodules, and example modules are all functionally correct. -### Test Environment +#### Test Environment The easiest way to test the module is in an isolated test project. The setup for such a project is defined in [test/setup](./test/setup/) directory. To use this setup, you need a service account with these permissions (on a Folder or Organization): @@ -67,12 +88,12 @@ With these settings in place, you can prepare a test project using Docker: make docker_test_prepare ``` -### Noninteractive Execution +#### Noninteractive Execution Run `make docker_test_integration` to test all of the example modules noninteractively, using the prepared test project. -### Interactive Execution +#### Interactive Execution 1. Run `make docker_run` to start the testing Docker container in interactive mode. @@ -87,12 +108,12 @@ noninteractively, using the prepared test project. 1. Run `kitchen_do destroy ` to destroy the example module state. -## Linting and Formatting +### Linting and Formatting Many of the files in the repository can be linted or formatted to maintain a standard of quality. -### Execution +#### Execution Run `make docker_test_lint`.