Create a pull request (PR) #
Requirements #
- 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.
- 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. ReplaceGITHUB_ISSUE_LINK
with a link to a GitHub issue from the provider issue tracker. - Write release notes
- Make sure the PR body includes the text
Code review #
- A reviewer will automatically be assigned to your PR.
- 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.
- 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:
- 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.
- 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.
- 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.
- Review the “diff generation” report to make sure the generated code looks as expected.
- 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.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.
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.