diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index d4f7bc9fe2f..e84c7aed138 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -195,6 +195,9 @@ for what to do. Travis CI build will fail if `go fmt` has not been run on incoming code.) The PR reviewers can help out on this front, and may provide comments with suggestions on how to improve the code. + - [ ] __Vendor additions__: Create a separate PR if you are updating the vendor + folder. This is to avoid conflicts as the vendor versions tend to be fast + moving targets. #### New Resource @@ -220,6 +223,9 @@ existing resources, but you still get to implement something completely new. Travis CI build will fail if `go fmt` has not been run on incoming code.) The PR reviewers can help out on this front, and may provide comments with suggestions on how to improve the code. + - [ ] __Vendor updates__: Create a separate PR if you are adding to the vendor + folder. This is to avoid conflicts as the vendor versions tend to be fast + moving targets. #### New Provider @@ -247,60 +253,6 @@ into Terraform. The PR reviewers can help out on this front, and may provide comments with suggestions on how to improve the code. -#### Core Bugfix/Enhancement - -We are always happy when any developer is interested in diving into Terraform's -core to help out! Here's what we look for in smaller Core PRs. - - - [ ] __Unit tests__: Terraform's core is covered by hundreds of unit tests at - several different layers of abstraction. Generally the best place to start - is with a "Context Test". These are higher level test that interact - end-to-end with most of Terraform's core. They are divided into test files - for each major action (plan, apply, etc.). Getting a failing test is a great - way to prove out a bug report or a new enhancement. With a context test in - place, you can work on implementation and lower level unit tests. Lower - level tests are largely context dependent, but the Context Tests are almost - always part of core work. - - [ ] __Documentation updates__: If the core change involves anything that - needs to be reflected in our documentation, you can make those changes in - the same PR. The [Terraform website][website] source is in this repo and - includes instructions for getting a local copy of the site up and running if - you'd like to preview your changes. - - [ ] __Well-formed Code__: Do your best to follow existing conventions you - see in the codebase, and ensure your code is formatted with `go fmt`. (The - Travis CI build will fail if `go fmt` has not been run on incoming code.) - The PR reviewers can help out on this front, and may provide comments with - suggestions on how to improve the code. - -#### Core Feature - -If you're interested in taking on a larger core feature, it's a good idea to -get feedback early and often on the effort. - - - [ ] __Early validation of idea and implementation plan__: Terraform's core - is complicated enough that there are often several ways to implement - something, each of which has different implications and tradeoffs. Working - through a plan of attack with the team before you dive into implementation - will help ensure that you're working in the right direction. - - [ ] __Unit tests__: Terraform's core is covered by hundreds of unit tests at - several different layers of abstraction. Generally the best place to start - is with a "Context Test". These are higher level test that interact - end-to-end with most of Terraform's core. They are divided into test files - for each major action (plan, apply, etc.). Getting a failing test is a great - way to prove out a bug report or a new enhancement. With a context test in - place, you can work on implementation and lower level unit tests. Lower - level tests are largely context dependent, but the Context Tests are almost - always part of core work. - - [ ] __Documentation updates__: If the core change involves anything that - needs to be reflected in our documentation, you can make those changes in - the same PR. The [Terraform website][website] source is in this repo and - includes instructions for getting a local copy of the site up and running if - you'd like to preview your changes. - - [ ] __Well-formed Code__: Do your best to follow existing conventions you - see in the codebase, and ensure your code is formatted with `go fmt`. (The - Travis CI build will fail if `go fmt` has not been run on incoming code.) - The PR reviewers can help out on this front, and may provide comments with - suggestions on how to improve the code. ### Writing Acceptance Tests @@ -326,14 +278,13 @@ Acceptance tests can be run using the `testacc` target in the Terraform expression. Prior to running the tests provider configuration details such as access keys must be made available as environment variables. -For example, to run an acceptance test against the Azure Resource Manager +For example, to run an acceptance test against the Amazon Web Services provider, the following environment variables must be set: ```sh -export ARM_SUBSCRIPTION_ID=... -export ARM_CLIENT_ID=... -export ARM_CLIENT_SECRET=... -export ARM_TENANT_ID=... +export AWS_ACCESS_KEY_ID=... +export AWS_SECRET_ACCESS_KEY=... +export AWS_DEFAULT_REGION=... ``` Tests can then be run by specifying the target provider and a regular