Create a pull request (PR) #

Requirements #

1. Make sure your branch contains a single self-contained change. For example:
   • If you are adding multiple resources to the provider, only put one resource in each PR - even if the product requires all resources to be present before it can be meaningfully used.
   • If you are adding a few fields and also fixing a bug, create one PR for adding the new fields and a separate PR for the bugs.
2. Follow the instructions at Creating a pull request to create a pull request to merge your branch into GoogleCloudPlatform/magic-modules.
   • Make sure the PR body includes the text Fixes GITHUB_ISSUE_LINK. once per issue resolved by your PR. Replace GITHUB_ISSUE_LINK with a link to a GitHub issue from the provider issue tracker.
   • Write release notes

Code review #

1. A reviewer will automatically be assigned to your PR.
2. Creating a new pull request or pushing a new commit automatically triggers our CI pipelines and workflows. After CI starts, downstream diff generation takes about 10 minutes; VCR tests can take up to 2 hours. If you are a community contributor, some tests will only run after approval from a reviewer.
   • While convenient, relying on CI to test iterative changes to PRs often adds extreme latency to reviews if there are errors in test configurations or at runtime. We strongly recommend you test your changes locally before pushing even after the initial change.
   • VCR tests will first attempt to play back recorded HTTP requests (REPLAYING mode). If any tests fail, they will run in RECORDING mode to generate a new cassette; then, the same tests will run again in REPLAYING mode to detect any nondeterministic behavior in the test (which can cause flaky tests.)
3. If your assigned reviewer does not respond to changes on a pull request within two US business days, ping them on the pull request.

TIP: Speeding up review:

1. Test your changes locally before pushing to iterate faster.
   • You can push them and test in parallel as well. New CI runs will preempt old ones where possible.
2. Resolve failed status checks quickly
   • Directly ask your reviewer for help if you don’t know how to proceed. If there are failed checks they may only check in if there’s no progress after a couple days.
3. Self-review your PR or ask someone else familiar with Terraform to review

Troubleshoot status check failures #

Provider unit tests or VCR tests #

VCR test failures that do not immediately seem related to your PR are most likely safe to ignore unless your reviewer says otherwise.

1. Review the “diff generation” report to make sure the generated code looks as expected.
2. Check out the generated code for your PR to run tests and iterate locally. For handwritten code or custom code, you can iterate directly in the provider and then copy the changes to your magic-modules branch once you have resolved the issue.
   terraform-provider-google

   cd $GOPATH/src/github.com/hashicorp/terraform-provider-google
   git checkout -- . && git clean -f google/ google-beta/ website/
   git remote add modular-magician https://github.com/modular-magician/terraform-provider-google.git
   git fetch modular-magician
   git checkout modular-magician/auto-pr-PR_NUMBER
   make test
   make lint
   make testacc TEST=./google/services/container TESTARGS='-run=TestAccContainerNodePool'
   

   Replace PR_NUMBER with your PR’s ID.

   terraform-provider-google-beta

   cd $GOPATH/src/github.com/hashicorp/terraform-provider-google-beta
   git checkout -- . && git clean -f google/ google-beta/ website/
   git remote add modular-magician https://github.com/modular-magician/terraform-provider-google-beta.git
   git fetch modular-magician
   git checkout modular-magician/auto-pr-PR_NUMBER
   make test
   make lint
   make testacc TEST=./google/services/container TESTARGS='-run=TestAccContainerNodePool'
   

   Replace PR_NUMBER with your PR’s ID.