Tests are run against an actual backend so they require a valid backend address
and token.
1.`TFE_ADDRESS` - URL of a Terraform Cloud or Terraform Enterprise instance to be used for testing, including scheme. Example: `https://tfe.local`
1.`TFE_TOKEN` - A [user API token](https://www.terraform.io/docs/cloud/users-teams-organizations/users.html#api-tokens) for the Terraform Cloud or Terraform Enterprise instance being used for testing.
##### Optional:
1.`GITHUB_TOKEN` - [GitHub personal access token](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line). Required for running OAuth client tests.
1.`GITHUB_POLICY_SET_IDENTIFIER` - GitHub policy set repository identifier in the format `username/repository`. Required for running policy set tests.
You can set your environment variables up however you prefer. The following are instructions for setting up environment variables using [envchain](https://github.com/sorah/envchain).
1. Make sure you have envchain installed. [Instructions for this can be found in the envchain README](https://github.com/sorah/envchain#installation).
1. Pick a namespace for storing your environment variables. I suggest `go-tfe` or something similar.
1. For each environment variable you need to set, run the following command:
Documentation updates and test fixes that only touch test files don't require a release or tag. You can just merge these changes into master once they have been approved.
### Creating a release
1. Merge your approved branch into master.
1. [Create a new release in GitHub](https://help.github.com/en/github/administering-a-repository/creating-releases).
- Click on "Releases" and then "Draft a new release"
- Set the `tag version` to a new tag, using [Semantic Versioning](https://semver.org/) as a guideline.
- Set the `target` as master.
- Set the `Release title` to the tag you created, `vX.Y.Z`
- Use the description section to describe why you're releasing and what changes you've made. You should include links to merged PRs
- Consider using the following headers in the description of your release:
- BREAKING CHANGES: Use this for any changes that aren't backwards compatible. Include details on how to handle these changes.
- FEATURES: Use this for any large new features added,
- ENHANCEMENTS: Use this for smaller new features added
- BUG FIXES: Use this for any bugs that were fixed.
- NOTES: Use this section if you need to include any additional notes on things like upgrading, upcoming deprecations, or any other information you might want to highlight.
Markdown example:
```markdown
ENHANCEMENTS
* Add description of new small feature (#3)[link-to-pull-request]
BUG FIXES
* Fix description of a bug (#2)[link-to-pull-request]
* Fix description of another bug (#1)[link-to-pull-request]
```
- Don't attach any binaries. The zip and tar.gz assets are automatically created and attached after you publish your release.
- Click "Publish release" to save and publish your release.