Skip to content

Latest commit

 

History

History
89 lines (67 loc) · 5.21 KB

CONTRIBUTING.md

File metadata and controls

89 lines (67 loc) · 5.21 KB
Raw

Contributing to Terraform Provider Google

This provider is generated by Magic Modules, and the repository contents are effectively read-only.

To get started making a contribution, see https://github.com/GoogleCloudPlatform/magic-modules#magic-modules.

Documentation not yet migrated

Most content on this page has been migrated to the Magic Modules README (https://github.com/GoogleCloudPlatform/magic-modules). The remaining sections in this document have not made it over yet; most are maintainer-specific.

Ensuring no plan-time difference to latest provider release (optional)

In a case where you are editing an existing field you might want to ensure the resource you are modifying doesn't result in a diff to existing deployments. You can run set the environment variable RELEASE_DIFF before running a test. This will append plan only steps using the latest released/published provider (google or google-beta) after all configuration deployments to ensure uniformity.

export RELEASE_DIFF=true
TF_LOG=TRACE make testacc TEST=./google TESTARGS='-run=TestAccContainerNodePool_basic' > output.log

Sweepers

Running provider tests often can lead to dangling test resources caused by test failures. Terraform has a capability to run Sweepers which can go through and delete resources. In TPG, sweepers mainly:

  1. List every resource in a project of a specific kind
  2. Iterate through the list and determine if a resource is sweepable
  3. If sweepable, delete the resource

Sweepers run by using the -sweep and -sweep-run TESTARGS flags:

TF_LOG=TRACE make testacc TEST=./google TESTARGS='-sweep=us-central1 -sweep-run=<sweeper-name-here>' > output.log

Maintainer-specific information

Reviewing / Merging Code

When reviewing/merging code, roughly follow the guidelines set in the Maintainer's Etiquette guide. One caveat is that they're fairly old and apply primarily to HashiCorp employees, but the general guidance about merging / changelogs is still relevant.

Upstreaming community PRs to Magic Modules

We recommend that the majority of contributors contribute directly to Magic Modules rather than directly to this repo, as we're much more able to run automated tests against PRs in that repository. If a contributor is unable to contribute to that repository but can contribute here, we're able to semi-automatically upstream changes with the following after conducting a primary review in this repo:

When contributors update handwritten files, we've got a couple bash fns to make the process simpler. Define the following in your .bashrc or .bash_profile.

function tpgpatch1 {
  pr_username=$(echo $1 | cut -d ':' -f1)
  feature_branch=$(echo $1 | cut -d ':' -f2)
  git remote add $pr_username git@github.com:$pr_username/${PWD##*/}
  git fetch $pr_username
  git checkout $pr_username/$feature_branch
  git format-patch $(git merge-base HEAD master)
}

function tpgpatch2 {
  for patch in $GOPATH/src/github.com/hashicorp/terraform-provider-google*/*.patch; do
    echo "checking ${patch}"
        if git apply --stat $patch | grep "google/"; then
                git am -3 -i $patch -p2 --directory=third_party/terraform/resources/ --include="*.go"
        fi
        if git apply --stat $patch | grep "google-beta/"; then
                git am -3 -i $patch -p2 --directory=third_party/terraform/resources/ --include="*.go"
        fi
        if git apply --stat $patch | grep "markdown"; then
                git am -3 -i $patch --directory=third_party/terraform/ --include="*website/*"
        fi
  done
}

With those functions defined:

  1. Check out both the provider and MM repo to master, committing/stashing any local changes
  2. In the MM repo, run git checkout -b {{branch}} to create a branch for your upstreaming PR
  3. Click the clipboard button next to the author:branch indicator on the PR to copy it.
  4. Run tpgpatch1 author:branch from the provider repo
  5. Run tpgpatch2 from the MM repo
  6. Remove the patch files from the provider repo

At this point, you should be checked out to a branch with the changes to handwritten files included in the MM repo. For generated files and most compiled files, you'll need to perform the upstreaming manually. After getting your local branch ready:

  1. Open a PR in MM with a complete release note, and edit the PR in this repo to include it
  2. Assign a reviewer- generally they'll rubberstamp the change, since it's already been approved
    • You can ignore CLA notices for third_party-only changes, it's not subject to it.
  3. Once approved, merge the PR here followed by the MM PR. The Magician will correct any deltas between the original code & the MM change, generally just minor formatting such as whitespace.