IntenseWebs/opentofu
3
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2025-02-25 18:45:20 -06:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'main' into update-internal-bakcend-user-facing

Browse Source
This commit is contained in:
Elbaz 2023-08-22 12:26:05 +03:00
commit 19fbfe54a5
34 changed files with 112 additions and 575 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.github/CODE_OF_CONDUCT.md vendored
View File

@ -1,5 +0,0 @@
# Code of Conduct
HashiCorp Community Guidelines apply to you when interacting with the community here on GitHub and contributing code.
Please read the full text at https://www.hashicorp.com/community-guidelines

179
.github/CONTRIBUTING.md vendored
View File

@ -1,161 +1,67 @@
# Contributing to Terraform
# Contributing to OpenTF
This repository contains only Terraform core, which includes the command line interface and the main graph engine. Providers are implemented as plugins that each have their own repository linked from the [Terraform Registry index](https://registry.terraform.io/browse/providers). Instructions for developing each provider are usually in the associated README file. For more information, see [the provider development overview](https://www.terraform.io/docs/plugins/provider.html).
This repository contains OpenTF core, which includes the command line interface and the main graph engine
**All communication on GitHub, the community forum, and other HashiCorp-provided communication channels is subject to [the HashiCorp community guidelines](https://www.hashicorp.com/community-guidelines).**
This document provides guidance on OpenTF contribution recommended practices. It covers what we're looking for in order to help set some expectations and help you get the most out of participation in this project.
This document provides guidance on Terraform contribution recommended practices. It covers what we're looking for in order to help set some expectations and help you get the most out of participation in this project.
To record a bug report, enhancement proposal, or give any other product feedback, please [open a GitHub issue](https://github.com/placeholderplaceholderplaceholder/opentf/issues/new/choose) using the most appropriate issue template
To record a bug report, enhancement proposal, or give any other product feedback, please [open a GitHub issue](https://github.com/placeholderplaceholderplaceholder/opentf/issues/new/choose) using the most appropriate issue template. Please do fill in all of the information the issue templates request, because we've seen from experience that this will maximize the chance that we'll be able to act on your feedback.
The contribution guideline will change in the near future, as the management of the open-source project is stabilized
---
<!-- MarkdownTOC autolink="true" -->
- [Contributing Fixes](#contributing-fixes)
- [Proposing a Change](#proposing-a-change)
- [Caveats & areas of special concern](#caveats--areas-of-special-concern)
- [State Storage Backends](#state-storage-backends)
- [Provisioners](#provisioners)
- [Maintainers](#maintainers)
- [Pull Request Lifecycle](#pull-request-lifecycle)
- [Getting Your Pull Requests Merged Faster](#getting-your-pull-requests-merged-faster)
- [PR Checks](#pr-checks)
- [Terraform CLI/Core Development Environment](#terraform-clicore-development-environment)
- [PR Checks](#pr-checks)
- [OpenTF CLI/Core Development Environment](#opentf-clicore-development-environment)
- [Acceptance Tests: Testing interactions with external services](#acceptance-tests-testing-interactions-with-external-services)
- [Generated Code](#generated-code)
- [External Dependencies](#external-dependencies)
<!-- /MarkdownTOC -->
## Contributing Fixes
It can be tempting to want to dive into an open source project and help _build the thing_ you believe you're missing. It's a wonderful and helpful intention. However, Terraform is a complex tool. Many seemingly simple changes can have serious effects on other areas of the code and it can take some time to become familiar with the effects of even basic changes. The Terraform team is not immune to unintended and sometimes undesirable changes. We do take our work seriously, and appreciate the globally diverse community that relies on Terraform for workflows of all sizes and criticality.
As a result of Terraform's complexity and high bar for stability, the most straightforward way to start helping with the Terraform project is to pick an existing bug and [get to work](#terraform-clicore-development-environment).
For new contributors we've labeled a few issues with `Good First Issue` as a nod to issues which will help get you familiar with Terraform development, while also providing an onramp to the codebase itself.
Read the documentation, and don't be afraid to [ask questions](https://discuss.hashicorp.com/c/terraform-core/27).
## Proposing a Change
In order to be respectful of the time of community contributors, we aim to discuss potential changes in GitHub issues prior to implementation. That will allow us to give design feedback up front and set expectations about the scope of the change, and, for larger changes, how best to approach the work such that the Terraform team can review it and merge it along with other concurrent work.
If the bug you wish to fix or enhancement you wish to implement isn't already covered by a GitHub issue that contains feedback from the Terraform team, please do start a discussion (either in [a new GitHub issue](https://github.com/placeholderplaceholderplaceholder/opentf/issues/new/choose) or an existing one, as appropriate) before you invest significant development time. If you mention your intent to implement the change described in your issue, the Terraform team can, as best as possible, prioritize including implementation-related feedback in the subsequent discussion.
At this time, we do not have a formal process for reviewing outside proposals that significantly change Terraform's workflow, its primary usage patterns, and its language. Additionally, some seemingly simple proposals can have deep effects across Terraform, which is why we strongly suggest starting with an issue-based proposal.
For large proposals that could entail a significant design phase, we wish to be up front with potential contributors that, unfortunately, we are unlikely to be able to give prompt feedback. We are still interested to hear about your use-cases so that we can consider ways to meet them as part of other larger projects.
Most changes will involve updates to the test suite, and changes to Terraform's documentation. The Terraform team can advise on different testing strategies for specific scenarios, and may ask you to revise the specific phrasing of your proposed documentation prose to match better with the standard "voice" of Terraform's documentation.
This repository is primarily maintained by a small team at HashiCorp along with their other responsibilities, so unfortunately we cannot always respond promptly to pull requests, particularly if they do not relate to an existing GitHub issue where the Terraform team has already participated and indicated willingness to work on the issue or accept PRs for the proposal. We *are* grateful for all contributions however, and will give feedback on pull requests as soon as we're able.
### Caveats & areas of special concern
There are some areas of Terraform which are of special concern to the Terraform team.
#### State Storage Backends
The Terraform team is not merging PRs for new state storage backends at the current time. Our priority regarding state storage backends is to find maintainers for existing backends and remove those backends without maintainers.
Please see the [CODEOWNERS](https://github.com/placeholderplaceholderplaceholder/opentf/blob/main/CODEOWNERS) file for the status of a given backend. Community members with an interest in a particular standard backend are welcome to help maintain it.
Currently, merging state storage backends places a significant burden on the Terraform team. The team must set up an environment and cloud service provider account, or a new database/storage/key-value service, in order to build and test remote state storage backends. The time and complexity of doing so prevents us from moving Terraform forward in other ways.
We are working to remove ourselves from the critical path of state storage backends by moving them towards a plugin model. In the meantime, we won't be accepting new remote state backends into Terraform.
#### Provisioners
Provisioners are an area of concern in Terraform for a number of reasons. Chiefly, they are often used in the place of configuration management tools or custom providers.
There are two main types of provisioners in Terraform, the generic provisioners (`file`,`local-exec`, and `remote-exec`) and the tool-specific provisioners (`chef`, `habbitat`, `puppet` & `salt-masterless`). **The tool-specific provisioners [are deprecated](https://discuss.hashicorp.com/t/notice-terraform-to-begin-deprecation-of-vendor-tool-specific-provisioners-starting-in-terraform-0-13-4/13997).** In practice this means we will not be accepting PRs for these areas of the codebase.
From our [documentation](https://www.terraform.io/docs/provisioners/index.html):
> ... they [...] add a considerable amount of complexity and uncertainty to Terraform usage.[...] we still recommend attempting to solve it [your problem] using other techniques first, and use provisioners only if there is no other option.
The Terraform team is in the process of building a way forward which continues to decrease reliance on provisioners. In the mean time however, as our documentation indicates, they are a tool of last resort. As such expect that PRs and issues for provisioners are not high in priority.
Please see the [CODEOWNERS](https://github.com/placeholderplaceholderplaceholder/opentf/blob/main/CODEOWNERS) file for the status of a given provisioner. Community members with an interest in a particular provisioner are welcome to help maintain it.
#### Maintainers
Maintainers are key contributors to our Open Source project. They contribute their time and expertise and we ask that the community take extra special care to be mindful of this when interacting with them.
For code that has a listed maintainer or maintainers in our [CODEOWNERS](https://github.com/placeholderplaceholderplaceholder/opentf/blob/main/CODEOWNERS) file, the Terraform team will highlight them for participation in PRs which relate to the area of code they maintain. The expectation is that a maintainer will review the code and work with the PR contributor before the code is merged by the Terraform team.
There is no expectation on response time for our maintainers; they may be indisposed for prolonged periods of time. Please be patient. Discussions on when code becomes "unmaintained" will be on a case-by-case basis.
If an an unmaintained area of code interests you and you'd like to become a maintainer, you may simply make a PR against our [CODEOWNERS](https://github.com/placeholderplaceholderplaceholder/opentf/blob/main/CODEOWNERS) file with your github handle attached to the approriate area. If there is a maintainer or team of maintainers for that area, please coordinate with them as necessary.
### Pull Request Lifecycle
1. You are welcome to submit a [draft pull request](https://github.blog/2019-02-14-introducing-draft-pull-requests/) for commentary or review before it is fully completed. It's also a good idea to include specific questions or items you'd like feedback on.
2. Once you believe your pull request is ready to be merged you can create your pull request.
3. When time permits Terraform's core team members will look over your contribution and either merge, or provide comments letting you know if there is anything left to do. It may take some time for us to respond. We may also have questions that we need answered about the code, either because something doesn't make sense to us or because we want to understand your thought process. We kindly ask that you do not target specific team members.
4. If we have requested changes, you can either make those changes or, if you disagree with the suggested changes, we can have a conversation about our reasoning and agree on a path forward. This may be a multi-step process. Our view is that pull requests are a chance to collaborate, and we welcome conversations about how to do things better. It is the contributor's responsibility to address any changes requested. While reviewers are happy to give guidance, it is unsustainable for us to perform the coding work necessary to get a PR into a mergeable state.
5. Once all outstanding comments and checklist items have been addressed, your contribution will be merged! Merged PRs may or may not be included in the next release based on changes the Terraform teams deems as breaking or not. The core team takes care of updating the [CHANGELOG.md](https://github.com/placeholderplaceholderplaceholder/opentf/blob/main/CHANGELOG.md) as they merge.
6. In some cases, we might decide that a PR should be closed without merging. We'll make sure to provide clear reasoning when this happens. Following the recommended process above is one of the ways to ensure you don't spend time on a PR we can't or won't merge.
#### Getting Your Pull Requests Merged Faster
It is much easier to review pull requests that are:
1. Well-documented: Try to explain in the pull request comments what your change does, why you have made the change, and provide instructions for how to produce the new behavior introduced in the pull request. If you can, provide screen captures or terminal output to show what the changes look like. This helps the reviewers understand and test the change.
2. Small: Try to only make one change per pull request. If you found two bugs and want to fix them both, that's *awesome*, but it's still best to submit the fixes as separate pull requests. This makes it much easier for reviewers to keep in their heads all of the implications of individual code changes, and that means the PR takes less effort and energy to merge. In general, the smaller the pull request, the sooner reviewers will be able to make time to review it.
3. Passing Tests: Based on how much time we have, we may not review pull requests which aren't passing our tests (look below for advice on how to run unit tests). If you need help figuring out why tests are failing, please feel free to ask, but while we're happy to give guidance it is generally your responsibility to make sure that tests are passing. If your pull request changes an interface or invalidates an assumption that causes a bunch of tests to fail, then you need to fix those tests before we can merge your PR.
If we request changes, try to make those changes in a timely manner. Otherwise, PRs can go stale and be a lot more work for all of us to merge in the future.
Even with everyone making their best effort to be responsive, it can be time-consuming to get a PR merged. It can be frustrating to deal with the back-and-forth as we make sure that we understand the changes fully. Please bear with us, and please know that we appreciate the time and energy you put into the project.
If the bug you wish to fix or enhancement you wish to implement isn't already covered by a GitHub issue, please do start a discussion (either in [a new GitHub issue](https://github.com/placeholderplaceholderplaceholder/opentf/issues/new/choose) or an existing one, as appropriate) before you invest significant development time.
### PR Checks
The following checks run when a PR is opened:
- Contributor License Agreement (CLA): If this is your first contribution to Terraform you will be asked to sign the CLA.
- Tests: tests include unit tests and acceptance tests, and all tests must pass before a PR can be merged.
Test checks run when a PR is opened. Tests include unit tests and acceptance tests, and all tests must pass before a PR can be merged
----
## Terraform CLI/Core Development Environment
## OpenTF CLI/Core Development Environment
This repository contains the source code for Terraform CLI, which is the main component of Terraform that contains the core Terraform engine.
Terraform providers are not maintained in this repository; you can find relevant
repository and relevant issue tracker for each provider within the
[Terraform Registry index](https://registry.terraform.io/browse/providers).
This repository also does not include the source code for some other parts of the Terraform product including Terraform Cloud, Terraform Enterprise, and the Terraform Registry. Those components are not open source, though if you have feedback about them (including bug reports) please do feel free to [open a GitHub issue on this repository](https://github.com/placeholderplaceholderplaceholder/opentf/issues/new/choose).
This repository contains the source code for OpenTF CLI, which is the main component of OpenTF that contains the core OpenTF engine.
---
If you wish to work on the Terraform CLI source code, you'll first need to install the [Go](https://golang.org/) compiler and the version control system [Git](https://git-scm.com/).
If you wish to work on the OpenTF CLI source code, you'll first need to install the [Go](https://golang.org/) compiler and the version control system [Git](https://git-scm.com/).
At this time the Terraform development environment is targeting only Linux and Mac OS X systems. While Terraform itself is compatible with Windows, unfortunately the unit test suite currently contains Unix-specific assumptions around maximum path lengths, path separators, etc.
At this time the OpenTF development environment is targeting only Linux and Mac OS X systems. While OpenTF itself is compatible with Windows, unfortunately the unit test suite currently contains Unix-specific assumptions around maximum path lengths, path separators, etc.
Refer to the file [`.go-version`](https://github.com/placeholderplaceholderplaceholder/opentf/blob/main/.go-version) to see which version of Go Terraform is currently built with. Other versions will often work, but if you run into any build or testing problems please try with the specific Go version indicated. You can optionally simplify the installation of multiple specific versions of Go on your system by installing [`goenv`](https://github.com/syndbg/goenv), which reads `.go-version` and automatically selects the correct Go version.
Refer to the file [`.go-version`](https://github.com/placeholderplaceholderplaceholder/opentf/blob/main/.go-version) to see which version of Go OpenTF is currently built with. Other versions will often work, but if you run into any build or testing problems please try with the specific Go version indicated. You can optionally simplify the installation of multiple specific versions of Go on your system by installing [`goenv`](https://github.com/syndbg/goenv), which reads `.go-version` and automatically selects the correct Go version.
Use Git to clone this repository into a location of your choice. Terraform is using [Go Modules](https://blog.golang.org/using-go-modules), and so you should *not* clone it inside your `GOPATH`.
Use Git to clone this repository into a location of your choice. OpenTF is using [Go Modules](https://blog.golang.org/using-go-modules), and so you should *not* clone it inside your `GOPATH`.
Switch into the root directory of the cloned repository and build Terraform using the Go toolchain in the standard way:
Switch into the root directory of the cloned repository and build OpenTF using the Go toolchain in the standard way:
```
cd terraform
cd opentf
go install .
```
The first time you run the `go install` command, the Go toolchain will download any library dependencies that you don't already have in your Go modules cache. Subsequent builds will be faster because these dependencies will already be available on your local disk.
Once the compilation process succeeds, you can find a `terraform` executable in the Go executable directory. If you haven't overridden it with the `GOBIN` environment variable, the executable directory is the `bin` directory inside the directory returned by the following command:
Once the compilation process succeeds, you can find a `opentf` executable in the Go executable directory. If you haven't overridden it with the `GOBIN` environment variable, the executable directory is the `bin` directory inside the directory returned by the following command:
```
go env GOPATH
```
If you are planning to make changes to the Terraform source code, you should run the unit test suite before you start to make sure everything is initially passing:
If you are planning to make changes to the OpenTF source code, you should run the unit test suite before you start to make sure everything is initially passing:
```
go test ./...
@ -170,21 +76,21 @@ go test ./internal/addrs
## Acceptance Tests: Testing interactions with external services
Terraform's unit test suite is self-contained, using mocks and local files to help ensure that it can run offline and is unlikely to be broken by changes to outside systems.
OpenTF's unit test suite is self-contained, using mocks and local files to help ensure that it can run offline and is unlikely to be broken by changes to outside systems.
However, several Terraform components interact with external services, such as the automatic provider installation mechanism, the Terraform Registry, Terraform Cloud, etc.
However, several OpenTF components interact with external services.
There are some optional tests in the Terraform CLI codebase that *do* interact with external services, which we collectively refer to as "acceptance tests". You can enable these by setting the environment variable `TF_ACC=1` when running the tests. We recommend focusing only on the specific package you are working on when enabling acceptance tests, both because it can help the test run to complete faster and because you are less likely to encounter failures due to drift in systems unrelated to your current goal:
There are some optional tests in the OpenTF CLI codebase that *do* interact with external services, which we collectively refer to as "acceptance tests". You can enable these by setting the environment variable `TF_ACC=1` when running the tests. We recommend focusing only on the specific package you are working on when enabling acceptance tests, both because it can help the test run to complete faster and because you are less likely to encounter failures due to drift in systems unrelated to your current goal:
```
TF_ACC=1 go test ./internal/initwd
```
Because the acceptance tests depend on services outside of the Terraform codebase, and because the acceptance tests are usually used only when making changes to the systems they cover, it is common and expected that drift in those external systems will cause test failures. Because of this, prior to working on a system covered by acceptance tests it's important to run the existing tests for that system in an *unchanged* work tree first and respond to any test failures that preexist, to avoid misinterpreting such failures as bugs in your new changes.
Because the acceptance tests depend on services outside of the OpenTF codebase, and because the acceptance tests are usually used only when making changes to the systems they cover, it is common and expected that drift in those external systems will cause test failures. Because of this, prior to working on a system covered by acceptance tests it's important to run the existing tests for that system in an *unchanged* work tree first and respond to any test failures that preexist, to avoid misinterpreting such failures as bugs in your new changes.
## Generated Code
Some files in the Terraform CLI codebase are generated. In most cases, we update these using `go generate`, which is the standard way to encapsulate code generation steps in a Go codebase.
Some files in the OpenTF CLI codebase are generated. In most cases, we update these using `go generate`, which is the standard way to encapsulate code generation steps in a Go codebase.
```
go generate ./...
@ -192,43 +98,8 @@ go generate ./...
Use `git diff` afterwards to inspect the changes and ensure that they are what you expected.
Terraform includes generated Go stub code for the Terraform provider plugin protocol, which is defined using Protocol Buffers. Because the Protocol Buffers tools are not written in Go and thus cannot be automatically installed using `go get`, we follow a different process for generating these, which requires that you've already installed a suitable version of `protoc`:
OpenTF includes generated Go stub code for the OpenTF provider plugin protocol, which is defined using Protocol Buffers. Because the Protocol Buffers tools are not written in Go and thus cannot be automatically installed using `go get`, we follow a different process for generating these, which requires that you've already installed a suitable version of `protoc`:
```
make protobuf
```
## External Dependencies
Terraform uses Go Modules for dependency management.
Our dependency licensing policy for Terraform excludes proprietary licenses and "copyleft"-style licenses. We accept the common Mozilla Public License v2, MIT License, and BSD licenses. We will consider other open source licenses in similar spirit to those three, but if you plan to include such a dependency in a contribution we'd recommend opening a GitHub issue first to discuss what you intend to implement and what dependencies it will require so that the Terraform team can review the relevant licenses to for whether they meet our licensing needs.
If you need to add a new dependency to Terraform or update the selected version for an existing one, use `go get` from the root of the Terraform repository as follows:
```
go get github.com/hashicorp/hcl/v2@2.0.0
```
This command will download the requested version (2.0.0 in the above example) and record that version selection in the `go.mod` file. It will also record checksums for the module in the `go.sum`.
To complete the dependency change, clean up any redundancy in the module metadata files by running:
```
go mod tidy
```
To ensure that the upgrade has worked correctly, be sure to run the unit test suite at least once:
```
go test ./...
```
Because dependency changes affect a shared, top-level file, they are more likely than some other change types to become conflicted with other proposed changes during the code review process. For that reason, and to make dependency changes more visible in the change history, we prefer to record dependency changes as separate commits that include only the results of the above commands and the minimal set of changes to Terraform's own code for compatibility with the new version:
```
git add go.mod go.sum
git commit -m "go get github.com/hashicorp/hcl/v2@2.0.0"
```
You can then make use of the new or updated dependency in new code added in subsequent commits.

43
.github/ISSUE_TEMPLATE/bug_report.yml vendored
View File

@ -10,34 +10,25 @@ body:
value: |
# Thank you for opening an issue.
The [hashicorp/terraform](https://github.com/hashicorp/terraform) issue tracker is reserved for bug reports relating to the core Terraform CLI application and configuration language.
For general usage questions, please see: https://www.terraform.io/community.html.
## If your issue relates to:
* **Terraform Cloud/Enterprise**: please email tf-cloud@hashicorp.support or [open a new request](https://support.hashicorp.com/hc/en-us/requests/new).
* **AWS Terraform Provider**: Open an issue at [hashicorp/terraform-provider-aws](https://github.com/hashicorp/terraform-provider-aws/issues/new/choose).
* **Azure Terraform Provider**: Open an issue at [hashicorp/terraform-provider-azurerm](https://github.com/hashicorp/terraform-provider-azurerm/issues/new/choose).
* **Other Terraform Providers**: Please open an issue in the provider's own repository, which can be found by searching the [Terraform Registry](https://registry.terraform.io/browse/providers).
The [OpenTF](https://github.com/placeholderplaceholderplaceholder/opentf) issue tracker is reserved for bug reports relating to the core OpenTF CLI application and configuration language.
## Filing a bug report
To fix problems, we need clear reproduction cases - we need to be able to see it happen locally. A reproduction case is ideally something a Terraform Core engineer can git-clone or copy-paste and run immediately, without inventing any details or context.
To fix problems, we need clear reproduction cases - we need to be able to see it happen locally. A reproduction case is ideally something any engineer can git-clone or copy-paste and run immediately, without inventing any details or context.
* A short example can be directly copy-pasteable; longer examples should be in separate git repositories, especially if multiple files are needed
* Please include all needed context. For example, if you figured out that an expression can cause a crash, put the expression in a variable definition or a resource
* Set defaults on (or omit) any variables. The person reproducing it should not need to invent variable settings
* If multiple steps are required, such as running terraform twice, consider scripting it in a simple shell script. Providing a script can be easier than explaining what changes to make to the config between runs.
* If multiple steps are required, such as running opentf twice, consider scripting it in a simple shell script. Providing a script can be easier than explaining what changes to make to the config between runs.
* Omit any unneeded complexity: remove variables, conditional statements, functions, modules, providers, and resources that are not needed to trigger the bug
* When possible, use the [null resource](https://www.terraform.io/docs/providers/null/resource.html) provider rather than a real provider in order to minimize external dependencies. We know this isn't always feasible. The Terraform Core team doesn't have deep domain knowledge in every provider, or access to every cloud platform for reproduction cases.
- type: textarea
id: tf-version
attributes:
label: Terraform Version
description: Run `terraform version` to show the version, and paste the result below. If you are not running the latest version of Terraform, please try upgrading because your issue may have already been fixed.
label: OpenTF Version
description: Run `opentf version` to show the version, and paste the result below. If you are not running the latest version of OpenTF, please try upgrading because your issue may have already been fixed.
render: shell
placeholder: ...output of `terraform version`...
placeholder: ...output of `opentf version`...
value:
validations:
required: true
@ -45,12 +36,12 @@ body:
- type: textarea
id: tf-config
attributes:
label: Terraform Configuration Files
description: Paste the relevant parts of your Terraform configuration between the ``` marks below. For Terraform configs larger than a few resources, or that involve multiple files, please make a GitHub repository that we can clone, rather than copy-pasting multiple files in here.
label: OpenTF Configuration Files
description: Paste the relevant parts of your OpenTF configuration between the ``` marks below. For OpenTF configs larger than a few resources, or that involve multiple files, please make a GitHub repository that we can clone, rather than copy-pasting multiple files in here.
placeholder:
value: |
```terraform
...terraform config...
```hcl
...opentf config...
```
validations:
required: true
@ -59,7 +50,7 @@ body:
id: tf-debug
attributes:
label: Debug Output
description: Full debug output can be obtained by running Terraform with the environment variable `TF_LOG=trace`. Please create a GitHub Gist containing the debug output. Please do _not_ paste the debug output in the issue, since debug output is long. Debug output may contain sensitive information. Please review it before posting publicly.
description: Full debug output can be obtained by running OpenTF with the environment variable `TF_LOG=trace`. Please create a GitHub Gist containing the debug output. Please do _not_ paste the debug output in the issue, since debug output is long. Debug output may contain sensitive information. Please review it before posting publicly.
placeholder: ...link to gist...
value:
validations:
@ -88,11 +79,11 @@ body:
label: Steps to Reproduce
description: |
Please list the full steps required to reproduce the issue, for example:
1. `terraform init`
2. `terraform apply`
1. `opentf init`
2. `opentf apply`
placeholder: |
1. `terraform init`
2. `terraform apply`
1. `opentf init`
2. `opentf apply`
value:
validations:
required: true
@ -102,7 +93,7 @@ body:
label: Additional Context
description: |
Are there anything atypical about your situation that we should know?
For example: is Terraform running in a wrapper script or in a CI system? Are you passing any unusual command line options or environment variables to opt-in to non-default behavior?"
For example: is OpenTF running in a wrapper script or in a CI system? Are you passing any unusual command line options or environment variables to opt-in to non-default behavior?"
placeholder: Additional context...
value:
validations:
@ -114,7 +105,7 @@ body:
description: |
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:
```
- #6017
- #1
```
placeholder:
value:

21
.github/ISSUE_TEMPLATE/config.yml vendored
View File

@ -1,23 +1,4 @@
# Copyright (c) HashiCorp, Inc.
# SPDX-License-Identifier: MPL-2.0
blank_issues_enabled: false
contact_links:
- name: Terraform Cloud/Enterprise Troubleshooting and Feature Requests
url: https://support.hashicorp.com/hc/en-us/requests/new
about: For issues and feature requests related to the Terraform Cloud/Enterprise platform, please submit a HashiCorp support request or email tf-cloud@hashicorp.support
- name: AWS Terraform Provider Feedback and Questions
url: https://github.com/hashicorp/terraform-provider-aws
about: The AWS Terraform Provider has its own repository, any provider related issues or questions should be directed there.
- name: Azure Terraform Provider Feedback and Questions
url: https://github.com/hashicorp/terraform-provider-azurerm
about: The Azure Terraform Provider has its own repository, any provider related issues or questions should be directed there.
- name: Other Provider-related Feedback and Questions
url: https://registry.terraform.io/browse/providers
about: Each provider (e.g. GCP, Oracle, K8S, etc.) has its own repository, any provider related issues or questions should be directed to the appropriate issue tracker linked from the Registry.
- name: Provider Development Feedback and Questions
url: https://github.com/hashicorp/terraform-plugin-sdk/issues/new/choose
about: Plugin SDK has its own repository, any SDK and provider development related issues or questions should be directed there.
- name: Terraform Usage, Language, or Workflow Questions
url: https://discuss.hashicorp.com/c/terraform-core
about: Please ask and answer language or workflow related questions through the Terraform Core Community Forum.
blank_issues_enabled: true # For now, to allow to easily create a blank issue. Remove this later

10
.github/ISSUE_TEMPLATE/custom-issue.md vendored
View File

@ -1,10 +0,0 @@
---
name: Custom Issue
about: Custom Issue Format
title: ''
labels: ''
assignees: ''
---

76
.github/ISSUE_TEMPLATE/documentation_issue.yml vendored
View File

@ -1,76 +0,0 @@
# Copyright (c) HashiCorp, Inc.
# SPDX-License-Identifier: MPL-2.0
name: Documentation Issue
description: Report an issue or suggest a change in the documentation.
labels: ["documentation", "new"]
body:
- type: markdown
attributes:
value: |
# Thank you for opening a documentation change request.
Please only use the [hashicorp/terraform](https://github.com/hashicorp/terraform) `Documentation` issue type to report problems with the documentation on [https://www.terraform.io/docs](). Only technical writers (not engineers) monitor this issue type. Report Terraform bugs or feature requests with the `Bug report` or `Feature Request` issue types instead to get engineering attention.
For general usage questions, please see: https://www.terraform.io/community.html.
- type: textarea
id: tf-version
attributes:
label: Terraform Version
description: Run `terraform version` to show the version, and paste the result below. If you're not using the latest version, please check to see if something related to your request has already been implemented in a later version.
render: shell
placeholder: ...output of `terraform version`...
value:
validations:
required: true
- type: textarea
id: tf-affected-pages
attributes:
label: Affected Pages
description: |
Link to the pages relevant to your documentation change request.
placeholder:
value:
validations:
required: false
- type: textarea
id: tf-problem
attributes:
label: What is the docs issue?
description: What problems or suggestions do you have about the documentation?
placeholder:
value:
validations:
required: true
- type: textarea
id: tf-proposal
attributes:
label: Proposal
description: What documentation changes would fix this issue and where would you expect to find them? Are one or more page headings unclear? Do one or more pages need additional context, examples, or warnings? Do we need a new page or section dedicated to a specific topic? Your ideas help us understand what you and other users need from our documentation and how we can improve the content.
placeholder:
value:
validations:
required: false
- type: textarea
id: tf-references
attributes:
label: References
description: |
Are there any other open or closed GitHub issues related to the problem or solution you described? If so, list them below. For example:
```
- #6017
```
placeholder:
value:
validations:
required: false
- type: markdown
attributes:
value: |
**Note:** If the submit button is disabled and you have filled out all required fields, please check that you did not forget a **Title** for the issue.

26
.github/ISSUE_TEMPLATE/feature_request.yml vendored
View File

@ -10,23 +10,15 @@ body:
value: |
# Thank you for opening a feature request.
The [hashicorp/terraform](https://github.com/hashicorp/terraform) issue tracker is reserved for feature requests relating to the core Terraform CLI application and configuration language.
For general usage questions, please see: https://www.terraform.io/community.html.
## If your feature request relates to:
* **Terraform Cloud/Enterprise**: please email tf-cloud@hashicorp.support or [open a new request](https://support.hashicorp.com/hc/en-us/requests/new).
* **AWS Terraform Provider**: Open an issue at [hashicorp/terraform-provider-aws](https://github.com/hashicorp/terraform-provider-aws/issues/new/choose).
* **Azure Terraform Provider**: Open an issue at [hashicorp/terraform-provider-azurerm](https://github.com/hashicorp/terraform-provider-azurerm/issues/new/choose).
* **Other Terraform Providers**: Please open an issue in the provider's own repository, which can be found by searching the [Terraform Registry](https://registry.terraform.io/browse/providers).
The [OpenTF](https://github.com/placeholderplaceholderplaceholder/opentf) issue tracker is reserved for feature requests relating to the core OpenTF CLI application and configuration language.
- type: textarea
id: tf-version
attributes:
label: Terraform Version
description: Run `terraform version` to show the version, and paste the result below. If you're not using the latest version, please check to see if something related to your request has already been implemented in a later version.
label: OpenTF Version
description: Run `opentf version` to show the version, and paste the result below. If you're not using the latest version, please check to see if something related to your request has already been implemented in a later version.
render: shell
placeholder: ...output of `terraform version`...
placeholder: ...output of `opentf version`...
value:
validations:
required: true
@ -49,8 +41,8 @@ body:
attributes:
label: Attempted Solutions
description: |
If you've already tried to solve the problem within Terraform's existing features and found a limitation that prevented you from succeeding, please describe it below in as much detail as possible.
Ideally, this would include real configuration snippets that you tried, real Terraform command lines you ran, and what results you got in each case.
If you've already tried to solve the problem within OpenTF's existing features and found a limitation that prevented you from succeeding, please describe it below in as much detail as possible.
Ideally, this would include real configuration snippets that you tried, real OpenTF command lines you ran, and what results you got in each case.
Please remove any sensitive information such as passwords before sharing configuration snippets and command lines.
placeholder:
value:
@ -62,9 +54,9 @@ body:
attributes:
label: Proposal
description: |
If you have an idea for a way to address the problem via a change to Terraform features, please describe it below.
If you have an idea for a way to address the problem via a change to OpenTF features, please describe it below.
In this section, it's helpful to include specific examples of how what you are suggesting might look in configuration files, or on the command line, since that allows us to understand the full picture of what you are proposing.
If you're not sure of some details, don't worry! When we evaluate the feature request we may suggest modifications as necessary to work within the design constraints of Terraform Core.
If you're not sure of some details, don't worry! When we evaluate the feature request we may suggest modifications as necessary to work within the design constraints of OpenTF Core.
placeholder:
value:
validations:
@ -77,7 +69,7 @@ body:
description: |
Are there any other GitHub issues, whether open or closed, that are related to the problem you've described above or to the suggested solution? If so, please create a list below that mentions each of them. For example:
```
- #6017
- #1
```
placeholder:
value:

4
.github/SUPPORT.md vendored
View File

@ -1,4 +0,0 @@
# Support
If you have questions about Terraform usage, please feel free to create a topic
on [the official community forum](https://discuss.hashicorp.com/c/terraform-core).

4
.github/pull_request_template.md vendored
View File

@ -47,8 +47,8 @@ Choose a category, delete the others:
Write a short description of the user-facing change. Examples:
- `terraform show -json`: Fixed crash with sensitive set values.
- When rendering a diff, Terraform now quotes the name of any object attribute whose string representation is not a valid identifier.
- `opentf show -json`: Fixed crash with sensitive set values.
- When rendering a diff, OpenTF now quotes the name of any object attribute whose string representation is not a valid identifier.
- The local token configuration in the cloud and remote backend now has higher priority than a token specified in a credentials block in the CLI configuration.
-->

85
BUGPROCESS.md
View File

@ -1,85 +0,0 @@
# Terraform Core GitHub Bug Triage & Labeling
The Terraform Core team has adopted a more structured bug triage process than we previously used. Our goal is to respond to reports of issues quickly.
When a bug report is filed, our goal is to either:
1. Get it to a state where it is ready for engineering to fix it in an upcoming Terraform release, or
2. Close it and explain why, if we can't help
## Process
### 1. [Newly created issues](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Anew+label%3Abug+-label%3Abackend%2Fk8s+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+-label%3A%22waiting-response%22+-label%3Aexplained+) require initial filtering.
These are raw reports that need categorization and support clarifying them. They need the following done:
* label backends, provisioners, and providers so we can route work on codebases we don't support to the correct teams
* point requests for help to the community forum and close the issue
* close reports against old versions we no longer support
* prompt users who have submitted obviously incomplete reproduction cases for additional information
If an issue requires discussion with the user to get it out of this initial state, leave "new" on there and label it "waiting-response" until this phase of triage is done.
Once this initial filtering has been done, remove the new label. If an issue subjectively looks very high-impact and likely to impact many users, assign it to the [appropriate milestone](https://github.com/placeholderplaceholderplaceholder/opentf/milestones) to mark it as being urgent.
### 2. Clarify [unreproduced issues](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+created%3A%3E2020-05-01+-label%3Abackend%2Fk8s+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Acreated-asc+)
A core team member initially determines whether the issue is immediately reproducible. If they cannot readily reproduce it, they label it "waiting for reproduction" and correspond with the reporter to describe what is needed. When the issue is reproduced by a core team member, they label it "confirmed".
"confirmed" issues should have a clear reproduction case. Anyone who picks it up should be able to reproduce it readily without having to invent any details.
Note that the link above excludes issues reported before May 2020; this is to avoid including issues that were reported prior to this new process being implemented. [Unreproduced issues reported before May 2020](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+created%3A%3C2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Areactions-%2B1-desc) will be triaged as capacity permits.
### 3. Explain or fix [confirmed issues](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fk8s+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+)
The next step for confirmed issues is to either:
* explain why the behavior is expected, label the issue as "working as designed", and close it, or
* locate the cause of the defect in the codebase. When the defect is located, and that description is posted on the issue, the issue is labeled "explained". In many cases, this step will get skipped if the fix is obvious, and engineers will jump forward and make a PR.
[Confirmed crashes](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Acrash+label%3Abug+-label%3Abackend%2Fk8s+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) should generally be considered high impact
### 4. The last step for [explained issues](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+label%3Aexplained+no%3Amilestone+-label%3Abackend%2Fk8s+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) is to make a PR to fix them.
Explained issues that are expected to be fixed in a future release should be assigned to a milestone
## GitHub Issue Labels
label | description
------------------------ | -----------
new | new issue not yet triaged
explained | a Terraform Core team member has described the root cause of this issue in code
waiting for reproduction | unable to reproduce issue without further information
not reproducible | closed because a reproduction case could not be generated
duplicate | issue closed because another issue already tracks this problem
confirmed | a Terraform Core team member has reproduced this issue
working as designed | confirmed as reported and closed because the behavior is intended
pending project | issue is confirmed but will require a significant project to fix
## Lack of response and unreproducible issues
When bugs that have been [labeled waiting response](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fk8s+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+label%3Awaiting-response+-label%3Aexplained+sort%3Aupdated-asc+) or [labeled "waiting for reproduction"](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+label%3A%22waiting+for+reproduction%22+-label%3Aexplained+sort%3Aupdated-asc+) for more than 30 days, we'll use our best judgement to determine whether it's more helpful to close it or prompt the reporter again. If they again go without a response for 30 days, they can be closed with a polite message explaining why and inviting the person to submit the needed information or reproduction case in the future.
The intent of this process is to get fix the maximum number of bugs in Terraform as quickly as possible, and having un-actionable bug reports makes it harder for Terraform Core team members and community contributors to find bugs they can actually work on.
## Helpful GitHub Filters
### Triage Process
1. [Newly created issues](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Anew+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fk8s+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+-label%3A%22waiting-response%22+-label%3Aexplained+) require initial filtering.
2. Clarify [unreproduced issues](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+created%3A%3E2020-05-01+-label%3Abackend%2Fk8s+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Acreated-asc+)
3. Explain or fix [confirmed issues](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+-label%3Aexplained+-label%3Abackend%2Fk8s+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+). Prioritize [confirmed crashes](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Fk8s+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+).
4. Fix [explained issues](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+label%3Aexplained+no%3Amilestone+-label%3Abackend%2Fk8s+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+)
### Other Backlog
[Confirmed needs for documentation fixes](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+label%3Adocumentation++label%3Aconfirmed+-label%3Abackend%2Fk8s+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+)
[Confirmed bugs that will require significant projects to fix](https://github.com/placeholderplaceholderplaceholder/opentf/issues?q=is%3Aopen+label%3Abug+label%3Aconfirmed+label%3A%22pending+project%22+-label%3Abackend%2Fk8s+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+)
### Milestone Use
Milestones ending in .x indicate issues assigned to that milestone are intended to be fixed during that release lifecycle. Milestones ending in .0 indicate issues that will be fixed in that major release. For example:
[0.13.x Milestone](https://github.com/placeholderplaceholderplaceholder/opentf/milestone/17). Issues in this milestone should be considered high-priority but do not block a patch release. All issues in this milestone should be resolved in a 13.x release before the 0.14.0 RC1 ships.
[0.14.0 Milestone](https://github.com/placeholderplaceholderplaceholder/opentf/milestone/18). All issues in this milestone must be fixed before 0.14.0 RC1 ships, and should ideally be fixed before 0.14.0 beta 1 ships.
[0.14.x Milestone](https://github.com/placeholderplaceholderplaceholder/opentf/milestone/20). Issues in this milestone are expected to be addressed at some point in the 0.14.x lifecycle, before 0.15.0. All issues in this milestone should be resolved in a 14.x release before the 0.15.0 RC1 ships.
[0.15.0 Milestone](https://github.com/placeholderplaceholderplaceholder/opentf/milestone/19). All issues in this milestone must be fixed before 0.15.0 RC1 ships, and should ideally be fixed before 0.15.0 beta 1 ships.

18
BUILDING.md
View File

@ -1,21 +1,19 @@
# Building from Source
Pre-built binaries are available for download for a variety of supported platforms through the [HashiCorp Releases website](https://releases.hashicorp.com/terraform/).
However, if you'd like to build Terraform yourself, you can do so using the Go build toolchain and the options specified in this document.
If you'd like to build OpenTF from source, you can do so using the Go build toolchain and the options specified in this document.
## Prerequisites
1. Ensure you've installed the Go language version specified in [`.go-version`](https://github.com/placeholderplaceholderplaceholder/opentf/blob/main/.go-version).
2. Clone this repository to a location of your choice.
## Terraform Build Options
## OpenTF Build Options
Terraform accepts certain options passed using `ldflags` at build time which control the behavior of the resulting binary.
OpenTF accepts certain options passed using `ldflags` at build time which control the behavior of the resulting binary.
### Dev Version Reporting
Terraform will include a `-dev` flag when reporting its own version (ex: 1.5.0-dev) unless `version.dev` is set to `no`:
OpenTF will include a `-dev` flag when reporting its own version (ex: 1.5.0-dev) unless `version.dev` is set to `no`:
```
go build -ldflags "-w -s -X 'github.com/placeholderplaceholderplaceholder/opentf/version.dev=no'" -o bin/ .
@ -23,20 +21,18 @@ go build -ldflags "-w -s -X 'github.com/placeholderplaceholderplaceholder/opentf
### Experimental Features
Experimental features of Terraform will be disabled unless `main.experimentsAllowed` is set to `yes`:
Experimental features of OpenTF will be disabled unless `main.experimentsAllowed` is set to `yes`:
```
go build -ldflags "-w -s -X 'main.experimentsAllowed=yes'" -o bin/ .
```
In the official build process for Terraform, experiments are only allowed in alpha release builds. We recommend that third-party distributors follow that convention in order to reduce user confusion.
## Go Options
For the most part, the Terraform release process relies on the Go toolchain defaults for the target operating system and processor architecture.
For the most part, the OpenTF release process relies on the Go toolchain defaults for the target operating system and processor architecture.
### `CGO_ENABLED`
One exception is the `CGO_ENABLED` option, which is set explicitly when building Terraform binaries. For most platforms, we build with `CGO_ENABLED=0` in order to produce a statically linked binary. For MacOS/Darwin operating systems, we build with `CGO_ENABLED=1` to avoid a platform-specific issue with DNS resolution.
One exception is the `CGO_ENABLED` option, which is set explicitly when building OpenTF binaries. For most platforms, we build with `CGO_ENABLED=0` in order to produce a statically linked binary. For MacOS/Darwin operating systems, we build with `CGO_ENABLED=1` to avoid a platform-specific issue with DNS resolution.

12
CHANGELOG.md
View File

@ -21,14 +21,4 @@ BUG FIXES:
For information on prior major and minor releases, see their changelogs:
* [v1.5](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v1.5/CHANGELOG.md)
* [v1.4](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v1.4/CHANGELOG.md)
* [v1.3](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v1.3/CHANGELOG.md)
* [v1.2](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v1.2/CHANGELOG.md)
* [v1.1](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v1.1/CHANGELOG.md)
* [v1.0](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v1.0/CHANGELOG.md)
* [v0.15](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v0.15/CHANGELOG.md)
* [v0.14](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v0.14/CHANGELOG.md)
* [v0.13](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v0.13/CHANGELOG.md)
* [v0.12](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v0.12/CHANGELOG.md)
* [v0.11 and earlier](https://github.com/placeholderplaceholderplaceholder/opentf/blob/v0.11/CHANGELOG.md)
None yet

28
CODEOWNERS
View File

@ -1,27 +1,7 @@
# Each line is a file pattern followed by one or more owners.
# More on CODEOWNERS files: https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners
# Remote-state backend # Maintainer
/internal/backend/remote-state/artifactory Unmaintained
/internal/backend/remote-state/azure @hashicorp/terraform-azure
/internal/backend/remote-state/consul @hashicorp/consul @remilapeyre
/internal/backend/remote-state/cos @likexian
/internal/backend/remote-state/etcdv2 Unmaintained
/internal/backend/remote-state/etcdv3 Unmaintained
/internal/backend/remote-state/gcs @hashicorp/terraform-google @hashicorp/terraform-ecosystem-strategic
/internal/backend/remote-state/http @hashicorp/terraform-core
/internal/backend/remote-state/manta Unmaintained
/internal/backend/remote-state/oss @xiaozhu36
/internal/backend/remote-state/pg @remilapeyre
/internal/backend/remote-state/s3 @hashicorp/terraform-aws
/internal/backend/remote-state/swift Unmaintained
/internal/backend/remote-state/kubernetes @jrhouston @alexsomesan
# Provisioners
builtin/provisioners/chef Deprecated
builtin/provisioners/file @hashicorp/terraform-core
builtin/provisioners/habitat Deprecated
builtin/provisioners/local-exec @hashicorp/terraform-core
builtin/provisioners/puppet Deprecated
builtin/provisioners/remote-exec @hashicorp/terraform-core
builtin/provisioners/salt-masterless Deprecated
# We currently do not have any specific code owners
# In the future, we will have a Github team of global code owners of the entire package
# Later on, we will start splitting up the responsibilities, and packages will be assigned more specific code owners
# * @opentf-code-owners

8
README.md
View File

@ -11,7 +11,7 @@ The key features of OpenTF are:
- **Infrastructure as Code**: Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.
- **Execution Plans**: OpenTF has a "planning" step where it generates an execution plan. The execution plan shows what Terraform will do when you call apply. This lets you avoid any surprises when OpenTF manipulates infrastructure.
- **Execution Plans**: OpenTF has a "planning" step where it generates an execution plan. The execution plan shows what OpenTF will do when you call apply. This lets you avoid any surprises when OpenTF manipulates infrastructure.
- **Resource Graph**: OpenTF builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, OpenTF builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.
@ -19,13 +19,11 @@ The key features of OpenTF are:
## Developing OpenTF
This repository contains only OpenTF core, which includes the command line interface and the main graph engine. Providers are implemented as plugins, and OpenTF can automatically download providers that are published on [the Terraform Registry](https://registry.terraform.io). For more information, see [Extending Terraform](https://www.terraform.io/docs/extend/index.html).
This repository contains only OpenTF core, which includes the command line interface and the main graph engine.
- To learn more about compiling OpenTF and contributing suggested changes, refer to [the contributing guide](.github/CONTRIBUTING.md).
- To learn more about how we handle bug reports, refer to the [bug triage guide](./BUGPROCESS.md).
- To learn how to contribute to the OpenTF documentation in this repository, refer to the [Terraform Documentation README](/website/README.md).
- To submit bug reports or enhancement requests, refer to the [the contributing guide](.github/CONTRIBUTING.md) as well.
## License

2
internal/addrs/check_rule_diagnostic.go
View File

@ -55,7 +55,7 @@ func (c *CheckRuleDiagnosticExtra) WrapDiagnosticExtra(inner interface{}) {
if c.wrapped != nil {
// This is a logical inconsistency, the caller should know whether they
// have already wrapped an extra or not.
panic("Attempted to wrap a diagnostic extra into a CheckRuleDiagnosticExtra that is already wrapping a different extra. This is a bug in Terraform, please report it.")
panic("Attempted to wrap a diagnostic extra into a CheckRuleDiagnosticExtra that is already wrapping a different extra. This is a bug in OpenTF, please report it.")
}
c.wrapped = inner
}

4
internal/addrs/doc.go
View File

@ -2,14 +2,14 @@
// SPDX-License-Identifier: MPL-2.0
// Package addrs contains types that represent "addresses", which are
// references to specific objects within a Terraform configuration or
// references to specific objects within a OpenTF configuration or
// state.
//
// All addresses have string representations based on HCL traversal syntax
// which should be used in the user-interface, and also in-memory
// representations that can be used internally.
//
// For object types that exist within Terraform modules a pair of types is
// For object types that exist within OpenTF modules a pair of types is
// used. The "local" part of the address is represented by a type, and then
// an absolute path to that object in the context of its module is represented
// by a type of the same name with an "Abs" prefix added, for "absolute".

2
internal/addrs/module_instance.go
View File

@ -198,7 +198,7 @@ LOOP:
// equivalent ModuleInstance address that assumes that no modules have
// keyed instances.
//
// This is a temporary allowance for the fact that Terraform does not presently
// This is a temporary allowance for the fact that OpenTF does not presently
// support "count" and "for_each" on modules, and thus graph building code that
// derives graph nodes from configuration must just assume unkeyed modules
// in order to construct the graph. At a later time when "count" and "for_each"

4
internal/addrs/module_package.go
View File

@ -7,9 +7,9 @@ import (
tfaddr "github.com/hashicorp/terraform-registry-address"
)
// A ModulePackage represents a physical location where Terraform can retrieve
// A ModulePackage represents a physical location where OpenTF can retrieve
// a module package, which is an archive, repository, or other similar
// container which delivers the source code for one or more Terraform modules.
// container which delivers the source code for one or more OpenTF modules.
//
// A ModulePackage is a string in go-getter's address syntax. By convention,
// we use ModulePackage-typed values only for the result of successfully

10
internal/addrs/module_source.go
View File

@ -54,7 +54,7 @@ var moduleSourceLocalPrefixes = []string{
// For historical reasons this syntax is a bit overloaded, supporting three
// different address types:
// - Local paths starting with either ./ or ../, which are special because
// Terraform considers them to belong to the same "package" as the caller.
// OpenTF considers them to belong to the same "package" as the caller.
// - Module registry addresses, given as either NAMESPACE/NAME/SYSTEM or
// HOST/NAMESPACE/NAME/SYSTEM, in which case the remote registry serves
// as an indirection over the third address type that follows.
@ -85,7 +85,7 @@ func ParseModuleSource(raw string) (ModuleSource, error) {
// parsed as one, and anything else must fall through to be
// parsed as a direct remote source, where go-getter might
// then recognize it as a filesystem path. This is odd
// but matches behavior we've had since Terraform v0.10 which
// but matches behavior we've had since OpenTF v0.10 which
// existing modules may be relying on.
// (Notice that this means that there's never any path where
// the registry source parse error gets returned to the caller,
@ -142,7 +142,7 @@ func parseModuleSourceLocal(raw string) (ModuleSourceLocal, error) {
// produces.
// Although using backslashes (Windows-style) is non-idiomatic, we do
// allow it and just normalize it away, so the rest of Terraform will
// allow it and just normalize it away, so the rest of OpenTF will
// only see the forward-slash form.
if strings.Contains(raw, `\`) {
// Note: We use string replacement rather than filepath.ToSlash
@ -192,12 +192,12 @@ func (s ModuleSourceLocal) ForDisplay() string {
}
// ModuleSourceRegistry is a ModuleSource representing a module listed in a
// Terraform module registry.
// OpenTF module registry.
//
// A registry source isn't a direct source location but rather an indirection
// over a ModuleSourceRemote. The job of a registry is to translate the
// combination of a ModuleSourceRegistry and a module version number into
// a concrete ModuleSourceRemote that Terraform will then download and
// a concrete ModuleSourceRemote that OpenTF will then download and
// install.
type ModuleSourceRegistry tfaddr.Module

4
internal/addrs/module_source_test.go
View File

@ -311,7 +311,7 @@ func TestParseModuleSource(t *testing.T) {
// just a general "this string doesn't match any of our source
// address patterns" situation, not _necessarily_ about relative
// local paths.
wantErr: `Terraform cannot detect a supported external module source type for boop/bloop`,
wantErr: `OpenTF cannot detect a supported external module source type for boop/bloop`,
},
"go-getter will accept all sorts of garbage": {
@ -481,7 +481,7 @@ func TestParseModuleSourceRegistry(t *testing.T) {
// the user provided in the input, and so for backward compatibility
// we're continuing to do that here, at the expense of now making the
// "ForDisplay" output case-preserving where its predecessor in the
// old package wasn't. The main Terraform Registry at registry.terraform.io
// old package wasn't. The main OpenTF Registry at registry.terraform.io
// is itself case-insensitive anyway, so our case-preserving here is
// entirely for the benefit of existing third-party registry
// implementations that might be case-sensitive, which we must remain

6
internal/addrs/move_endpoint.go
View File

@ -18,8 +18,8 @@ import (
// Its name reflects that its primary purpose is for the "from" and "to"
// addresses in a "moved" statement in the configuration, but it's also
// valid to use MoveEndpoint for other similar mechanisms that give
// Terraform hints about historical configuration changes that might
// prompt creating a different plan than Terraform would by default.
// OpenTF hints about historical configuration changes that might
// prompt creating a different plan than OpenTF would by default.
//
// To obtain a full address from a MoveEndpoint you must use
// either the package function UnifyMoveEndpoints (to get an AbsMoveable) or
@ -31,7 +31,7 @@ type MoveEndpoint struct {
SourceRange tfdiags.SourceRange
// Internally we (ab)use AbsMoveable as the representation of our
// relative address, even though everywhere else in Terraform
// relative address, even though everywhere else in OpenTF
// AbsMoveable always represents a fully-absolute address.
// In practice, due to the implementation of ParseMoveEndpoint,
// this is always either a ModuleInstance or an AbsResourceInstance,

2
internal/addrs/output_value.go
View File

@ -17,7 +17,7 @@ import (
//
// This is related to but separate from ModuleCallOutput, which represents
// a module output from the perspective of its parent module. Outputs are
// referencable from the testing scope, in general terraform operation users
// referencable from the testing scope, in general opentf operation users
// will be referencing ModuleCallOutput.
type OutputValue struct {
referenceable

8
internal/addrs/parse_ref.go
View File

@ -23,10 +23,10 @@ type Reference struct {
}
// DisplayString returns a string that approximates the subject and remaining
// traversal of the reciever in a way that resembles the Terraform language
// traversal of the reciever in a way that resembles the OpenTF language
// syntax that could've produced it.
//
// It's not guaranteed to actually be a valid Terraform language expression,
// It's not guaranteed to actually be a valid OpenTF language expression,
// since the intended use here is primarily for UI messages such as
// diagnostics.
func (r *Reference) DisplayString() string {
@ -209,7 +209,7 @@ func parseRef(traversal hcl.Traversal) (*Reference, tfdiags.Diagnostics) {
case "resource":
// This is an alias for the normal case of just using a managed resource
// type as a top-level symbol, which will serve as an escape mechanism
// if a later edition of the Terraform language introduces a new
// if a later edition of the OpenTF language introduces a new
// reference prefix that conflicts with a resource type name in an
// existing provider. In that case, the edition upgrade tool can
// rewrite foo.bar into resource.foo.bar to ensure that "foo" remains
@ -346,7 +346,7 @@ func parseRef(traversal hcl.Traversal) (*Reference, tfdiags.Diagnostics) {
diags = diags.Append(&hcl.Diagnostic{
Severity: hcl.DiagError,
Summary: "Reserved symbol name",
Detail: fmt.Sprintf("The symbol name %q is reserved for use in a future Terraform version. If you are using a provider that already uses this as a resource type name, add the prefix \"resource.\" to force interpretation as a resource type name.", root),
Detail: fmt.Sprintf("The symbol name %q is reserved for use in a future OpenTF version. If you are using a provider that already uses this as a resource type name, add the prefix \"resource.\" to force interpretation as a resource type name.", root),
Subject: rootRange.Ptr(),
})
return nil, diags

8
internal/addrs/parse_ref_test.go
View File

@ -697,7 +697,7 @@ func TestParseRef(t *testing.T) {
// the "resource" prefix forces interpreting the next name as a
// resource type name. This is an alias for just using a resource
// type name at the top level, to be used only if a later edition
// of the Terraform language introduces a new reserved word that
// of the OpenTF language introduces a new reserved word that
// overlaps with a resource type name.
{
`resource.boop_instance.foo`,
@ -721,17 +721,17 @@ func TestParseRef(t *testing.T) {
{
`template.foo`,
nil,
`The symbol name "template" is reserved for use in a future Terraform version. If you are using a provider that already uses this as a resource type name, add the prefix "resource." to force interpretation as a resource type name.`,
`The symbol name "template" is reserved for use in a future OpenTF version. If you are using a provider that already uses this as a resource type name, add the prefix "resource." to force interpretation as a resource type name.`,
},
{
`lazy.foo`,
nil,
`The symbol name "lazy" is reserved for use in a future Terraform version. If you are using a provider that already uses this as a resource type name, add the prefix "resource." to force interpretation as a resource type name.`,
`The symbol name "lazy" is reserved for use in a future OpenTF version. If you are using a provider that already uses this as a resource type name, add the prefix "resource." to force interpretation as a resource type name.`,
},
{
`arg.foo`,
nil,
`The symbol name "arg" is reserved for use in a future Terraform version. If you are using a provider that already uses this as a resource type name, add the prefix "resource." to force interpretation as a resource type name.`,
`The symbol name "arg" is reserved for use in a future OpenTF version. If you are using a provider that already uses this as a resource type name, add the prefix "resource." to force interpretation as a resource type name.`,
},
// anything else, interpreted as a managed resource reference

4
internal/addrs/provider.go
View File

@ -67,14 +67,14 @@ func NewProvider(hostname svchost.Hostname, namespace, typeName string) Provider
// As a special case, the string "terraform" maps to
// "terraform.io/builtin/terraform" because that is the more likely user
// intent than the now-unmaintained "registry.terraform.io/hashicorp/terraform"
// which remains only for compatibility with older Terraform versions.
// which remains only for compatibility with older OpenTF versions.
func ImpliedProviderForUnqualifiedType(typeName string) Provider {
switch typeName {
case "terraform":
// Note for future maintainers: any additional strings we add here
// as implied to be builtin must never also be use as provider names
// in the registry.terraform.io/hashicorp/... namespace, because
// otherwise older versions of Terraform could implicitly select
// otherwise older versions of OpenTF could implicitly select
// the registry name instead of the internal one.
return NewBuiltInProvider(typeName)
default:

8
internal/addrs/provider_config.go
View File

@ -233,7 +233,7 @@ func ParseLegacyAbsProviderConfigStr(str string) (AbsProviderConfig, tfdiags.Dia
}
// ParseLegacyAbsProviderConfig parses the given traversal as an absolute
// provider address in the legacy form used by Terraform v0.12 and earlier.
// provider address in the legacy form used by OpenTF v0.12 and earlier.
// The following are examples of traversals that can be successfully parsed as
// legacy absolute provider configuration addresses:
//
@ -244,8 +244,8 @@ func ParseLegacyAbsProviderConfigStr(str string) (AbsProviderConfig, tfdiags.Dia
//
// We can encounter this kind of address in a historical state snapshot that
// hasn't yet been upgraded by refreshing or applying a plan with
// Terraform v0.13. Later versions of Terraform reject state snapshots using
// this format, and so users must follow the Terraform v0.13 upgrade guide
// OpenTF v0.13. Later versions of OpenTF reject state snapshots using
// this format, and so users must follow the OpenTF v0.13 upgrade guide
// in that case.
//
// We will not use this address form for any new file formats.
@ -352,7 +352,7 @@ func (pc AbsProviderConfig) providerConfig() {}
// other than the root module. Even if a valid address is returned, inheritence
// may not be performed for other reasons, such as if the calling module
// provided explicit provider configurations within the call for this module.
// The ProviderTransformer graph transform in the main terraform module has the
// The ProviderTransformer graph transform in the main opentf module has the
// authoritative logic for provider inheritance, and this method is here mainly
// just for its benefit.
func (pc AbsProviderConfig) Inherited() (AbsProviderConfig, bool) {

64
internal/command/cliconfig/cliconfig_test.go
View File

@ -7,12 +7,10 @@ import (
"os"
"path/filepath"
"reflect"
"runtime"
"testing"
"github.com/davecgh/go-spew/spew"
"github.com/google/go-cmp/cmp"
"github.com/placeholderplaceholderplaceholder/opentf/internal/tfdiags"
)
@ -551,65 +549,3 @@ func TestConfig_Merge_disableCheckpointSignature(t *testing.T) {
t.Fatalf("bad: %#v", actual)
}
}
func TestConfigDir_BackwardsCompatibility(t *testing.T) {
dir, err := os.MkdirTemp("", "opentf_test")
if err != nil {
t.Fatalf("failed to create temp dir: %s", err)
}
defer os.RemoveAll(dir)
terraformdName := ".terraform.d"
opentfdName := ".opentf.d"
if runtime.GOOS == "windows" {
terraformdName = "terraform.d"
opentfdName = "opentf.d"
}
if err := os.Setenv("OPENTF_TEST_HOME", dir); err != nil {
t.Fatalf("failed to set env var: %s", err)
}
// The three tests below are grouped for logical ease of understanding, but they are not independent.
// They have to run in this exact order.
t.Run("when no dir exists, use .opentf.d", func(t *testing.T) {
loadedConfigDir, err := configDir()
if err != nil {
t.Fatalf("failed to get config dir: %s", err)
}
if loadedConfigDir != filepath.Join(dir, opentfdName) {
t.Fatalf("bad: %s", loadedConfigDir)
}
})
t.Run("when only .terraform.d exists, use .terraform.d for backwards-compatibility reasons", func(t *testing.T) {
if err := os.MkdirAll(filepath.Join(dir, terraformdName), 0755); err != nil {
t.Fatalf("failed to create temp dir: %s", err)
}
loadedConfigDir, err := configDir()
if err != nil {
t.Fatalf("failed to get config dir: %s", err)
}
if loadedConfigDir != filepath.Join(dir, terraformdName) {
t.Fatalf("bad: %s", loadedConfigDir)
}
})
t.Run("when both .terraform.d and .opentf.d exist, use .opentf.d", func(t *testing.T) {
if err := os.MkdirAll(filepath.Join(dir, opentfdName), 0755); err != nil {
t.Fatalf("failed to create temp dir: %s", err)
}
loadedConfigDir, err := configDir()
if err != nil {
t.Fatalf("failed to get config dir: %s", err)
}
if loadedConfigDir != filepath.Join(dir, opentfdName) {
t.Fatalf("bad: %s", loadedConfigDir)
}
})
}

10
internal/command/cliconfig/config_unix.go
View File

@ -31,18 +31,10 @@ func configDir() (string, error) {
return "", err
}
newConfigDir := filepath.Join(dir, ".opentf.d")
legacyConfigDir := filepath.Join(dir, ".terraform.d")
return getNewOrLegacyPath(newConfigDir, legacyConfigDir)
return filepath.Join(dir, ".terraform.d"), nil
}
func homeDir() (string, error) {
// For unit-testing purposes.
if home := os.Getenv("OPENTF_TEST_HOME"); home != "" {
return home, nil
}
// First prefer the HOME environmental variable
if home := os.Getenv("HOME"); home != "" {
// FIXME: homeDir gets called from globalPluginDirs during init, before

11
internal/command/cliconfig/config_windows.go
View File

@ -7,7 +7,6 @@
package cliconfig
import (
"os"
"path/filepath"
"syscall"
"unsafe"
@ -38,18 +37,10 @@ func configDir() (string, error) {
return "", err
}
newConfigDir := filepath.Join(dir, "opentf.d")
legacyConfigDir := filepath.Join(dir, "terraform.d")
return getNewOrLegacyPath(newConfigDir, legacyConfigDir)
return filepath.Join(dir, "terraform.d"), nil
}
func homeDir() (string, error) {
// For unit-testing purposes.
if home := os.Getenv("OPENTF_TEST_HOME"); home != "" {
return home, nil
}
b := make([]uint16, syscall.MAX_PATH)
// See: http://msdn.microsoft.com/en-us/library/windows/desktop/bb762181(v=vs.85).aspx

2
internal/getmodules/file_detector.go
View File

@ -64,5 +64,5 @@ type MaybeRelativePathErr struct {
}
func (e *MaybeRelativePathErr) Error() string {
return fmt.Sprintf("Terraform cannot detect a supported external module source type for %s", e.Addr)
return fmt.Sprintf("OpenTF cannot detect a supported external module source type for %s", e.Addr)
}

2
plugins.go
View File

@ -20,7 +20,7 @@ import (
// older versions where both satisfy the provider version constraints.
func globalPluginDirs() []string {
var ret []string
// Look in ~/.opentf.d/plugins/ , or its equivalent on non-UNIX
// Look in ~/.terraform.d/plugins/ , or its equivalent on non-UNIX
dir, err := cliconfig.ConfigDir()
if err != nil {
log.Printf("[ERROR] Error finding global config directory: %s", err)

2
provider_source.go
View File

@ -96,7 +96,7 @@ func implicitProviderSource(services *disco.Disco) getproviders.Source {
// way to include them in bundles uploaded to Terraform Cloud, where
// there has historically otherwise been no way to use custom providers.
// - The "plugins" subdirectory of the CLI config search directory.
// (thats ~/.opentf.d/plugins on Unix systems, equivalents elsewhere)
// (thats ~/.terraform.d/plugins on Unix systems, equivalents elsewhere)
// - The "plugins" subdirectory of any platform-specific search paths,
// following e.g. the XDG base directory specification on Unix systems,
// Apple's guidelines on OS X, and "known folders" on Windows.

13
website/docs/cli/config/config-file.mdx
View File

@ -46,7 +46,7 @@ general syntax; see the following section for information on the meaning
of each of these settings:
```hcl
plugin_cache_dir = "$HOME/.opentf.d/plugin-cache"
plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"
disable_checkpoint = true
```
@ -301,12 +301,11 @@ method.
The set of directories Terraform can select as filesystem mirrors depends on
the operating system where you are running Terraform:
* **Windows:** `%APPDATA%/opentf.d/plugins`, `%APPDATA%/terraform.d/plugins` and `%APPDATA%/HashiCorp/Terraform/plugins`
* **Mac OS X:** `$HOME/.opentf.d/plugins`,
`$HOME/.terraform.d/plugins`, and
* **Windows:** `%APPDATA%/terraform.d/plugins` and `%APPDATA%/HashiCorp/Terraform/plugins`
* **Mac OS X:** `$HOME/.terraform.d/plugins`,
`~/Library/Application Support/io.terraform/plugins`, and
`/Library/Application Support/io.terraform/plugins`
* **Linux and other Unix-like systems**:`$HOME/.opentf.d/plugins`, `$HOME/.terraform.d/plugins` and
* **Linux and other Unix-like systems**:`$HOME/.terraform.d/plugins` and
`terraform/plugins` located within a valid
[XDG Base Directory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)
data directory such as `$XDG_DATA_HOME/terraform/plugins`.
@ -348,7 +347,7 @@ To enable the plugin cache, use the `plugin_cache_dir` setting in
the CLI configuration file. For example:
```hcl
plugin_cache_dir = "$HOME/.opentf.d/plugin-cache"
plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"
```
This directory must already exist before Terraform will cache plugins;
@ -364,7 +363,7 @@ variable can be used to enable caching or to override an existing cache
directory within a particular shell session:
```bash
export TF_PLUGIN_CACHE_DIR="$HOME/.opentf.d/plugin-cache"
export TF_PLUGIN_CACHE_DIR="$HOME/.terraform.d/plugin-cache"
```
When a plugin cache directory is enabled, the `terraform init` command will

2
website/docs/language/resources/provisioners/syntax.mdx
View File

@ -202,7 +202,7 @@ provisioners must connect to the remote system using SSH or WinRM.
You must include [a `connection` block](/terraform/language/resources/provisioners/connection) so that Terraform knows how to communicate with the server.
Terraform includes several built-in provisioners. You can also use third-party provisioners as plugins, by placing them
in `%APPDATA%\opentf.d\plugins`, `~/.opentf.d/plugins`, or the same
in `%APPDATA%\terraform.d\plugins`, `~/.terraform.d/plugins`, or the same
directory where the Terraform binary is installed. However, we do not recommend
using any provisioners except the built-in `file`, `local-exec`, and
`remote-exec` provisioners.