jprdonnelly/opentf
1
0
Fork 0
mirror of https://github.com/opentffoundation/opentf.git synced 2025-12-19 17:59:05 -05:00
Code Issues Packages Projects Releases Wiki Activity

Renaming terraform to opentf

Browse Source
This commit is contained in:
Yaron Yarimi
2023-08-22 15:28:30 +03:00
parent da56f706e7
commit 24beb7ee5c
7 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/architecture.md
View File

@@ -20,7 +20,7 @@ in more detail in a corresponding section below.
## CLI (`command` package)
Each time a user runs the `terraform` program, aside from some initial
Each time a user runs the `opentf` program, aside from some initial
bootstrapping in the root package (not shown in the diagram) execution
transfers immediately into one of the "command" implementations in
[the `command` package](https://pkg.go.dev/github.com/placeholderplaceholderplaceholder/opentf/internal/command).
@@ -29,8 +29,8 @@ their corresponding `command` package types can be found in the `commands.go`
file in the root of the repository.
The full flow illustrated above does not actually apply to _all_ commands,
but it applies to the main OpenTF workflow commands `terraform plan` and
`terraform apply`, along with a few others.
but it applies to the main OpenTF workflow commands `opentf plan` and
`opentf apply`, along with a few others.
For these commands, the role of the command implementation is to read and parse
any command line arguments, command line options, and environment variables
@@ -69,7 +69,7 @@ backend and Terraform Cloud's backends (`remote`, `cloud`) perform operations.
Thus, most backends do _not_ implement this interface, and so the `command` package wraps these
backends in an instance of
[`local.Local`](https://pkg.go.dev/github.com/placeholderplaceholderplaceholder/opentf/internal/backend/local#Local),
causing the operation to be executed locally within the `terraform` process itself.
causing the operation to be executed locally within the `opentf` process itself.
## Backends
@@ -109,7 +109,7 @@ configuration objects, but the main entry point is in the sub-package
via
[`configload.Loader`](https://pkg.go.dev/github.com/placeholderplaceholderplaceholder/opentf/internal/configs/configload#Loader).
A loader deals with all of the details of installing child modules
(during `terraform init`) and then locating those modules again when a
(during `opentf init`) and then locating those modules again when a
configuration is loaded by a backend. It takes the path to a root module
and recursively loads all of the child modules to produce a single
[`configs.Config`](https://pkg.go.dev/github.com/placeholderplaceholderplaceholder/opentf/internal/configs#Config)

4
docs/plugin-protocol/README.md
View File

@@ -100,7 +100,7 @@ protocol version 5.0, since major version 5 is supported and the optional
5.1 and 5.2 enhancements will be ignored.
If OpenTF Core and the plugin do not have at least one mutually-supported
major version, OpenTF Core will return an error from `terraform init`
major version, OpenTF Core will return an error from `opentf init`
during plugin installation:
```
@@ -122,7 +122,7 @@ it with the following constraint:
Alternatively, upgrade to the latest version of OpenTF for compatibility with newer provider releases.
```
The above messages are for plugins installed via `terraform init` from a
The above messages are for plugins installed via `opentf init` from a
OpenTF registry, where the registry API allows OpenTF Core to recognize
the protocol compatibility for each provider release. For plugins that are
installed manually to a local plugin directory, OpenTF Core has no way to

8
docs/plugin-protocol/releasing-new-version.md
View File

@@ -8,7 +8,7 @@ everything that needs to be is aware of it.
## New Protobuf File
The protocol is defined in protobuf files that live in the hashicorp/terraform
The protocol is defined in protobuf files that live in the opentffoundation/opentf
repository. Adding a new version of the protocol involves creating a new
`.proto` file in that directory. It is recommended that you copy the latest
protocol file, and modify it accordingly.
@@ -32,9 +32,9 @@ support for the new protocol version until it is added to that list.
## Update OpenTF's Version Constraints
OpenTF only downloads providers that speak protocol versions it is
compatible with from the Registry during `terraform init`. When adding support
compatible with from the Registry during `opentf init`. When adding support
for a new protocol, you need to tell OpenTF it knows that protocol version.
Modify the `SupportedPluginProtocols` variable in hashicorp/terraform's
Modify the `SupportedPluginProtocols` variable in opentffoundation/opentf's
`internal/getproviders/registry_client.go` file to include the new protocol.
## Test Running a Provider With the Test Framework
@@ -47,7 +47,7 @@ the protocol version between the test framework and OpenTF.
## Test Retrieving and Running a Provider From the Registry
Publish a provider, either to the public registry or to the staging registry,
and test running `terraform init` and `terraform apply`, along with exercising
and test running `opentf init` and `opentf apply`, along with exercising
any of the new functionality the protocol version introduces. This end-to-end
test ensures that all the pieces needing to be updated before practitioners can
use providers built with the new protocol have been updated.

4
internal/cloud/e2e/README.md
View File

@@ -6,7 +6,7 @@ TFE_TOKEN=<token> TFE_HOSTNAME=<hostname> TF_ACC=1 go test ./internal/cloud/e2e
```
Required flags
* `TF_ACC=1`. This variable is used as part of terraform for tests that make
* `TF_ACC=1`. This variable is used as part of opentf for tests that make
external network calls. This is needed to run these tests. Without it, the
tests do not run.
* `TFE_TOKEN=<admin token>` and `TFE_HOSTNAME=<hostname>`. The helpers
@@ -16,7 +16,7 @@ for these tests require admin access to a TFC/TFE instance.
### Flags
* Use the `-v` flag for normal verbose mode.
* Use the `-tfoutput` flag to print the terraform output to standard out.
* Use the `-tfoutput` flag to print the opentf output to standard out.
* Use `-ldflags` to change the version Prerelease to match a version
available remotely. Some behaviors rely on the exact local version Terraform
being available in TFC/TFE, and manipulating the Prerelease during build is

4
internal/command/jsonformat/README.md
View File

@@ -10,7 +10,7 @@ As of January 2023, this package contains only a single structure: the
`Renderer`.
The renderer accepts the JSON structured output produced by the
`terraform show <plan-file> -json` command and writes it in a human-readable
`opentf show <plan-file> -json` command and writes it in a human-readable
format.
Implementation details and decisions for the `Renderer` are discussed in the
@@ -30,7 +30,7 @@ concerned with the complex diff calculations.
#### The `differ` package
The `differ` package operates on `Change` objects. These are produced from
`jsonplan.Change` objects (which are produced by the `terraform show` command).
`jsonplan.Change` objects (which are produced by the `opentf show` command).
Each `jsonplan.Change` object represents a single resource within the overall
Terraform configuration.

8
tools/terraform-bundle/README.md
View File

@@ -32,8 +32,8 @@ OpenTF v0.13.0 and later.
If you have a working toolchain for the Go programming language, you can
build a `terraform-bundle` executable as follows:
* `git clone --single-branch --branch=v0.15 --depth=1 https://github.com/hashicorp/terraform.git`
* `cd terraform`
* `git clone --single-branch --branch=v0.15 --depth=1 https://github.com/opentffoundation/opentf.git`
* `cd opentf`
* `go build -o ../terraform-bundle ./tools/terraform-bundle`
After running these commands, your original working directory will have an
@@ -42,7 +42,7 @@ executable named `terraform-bundle`, which you can then run.
For information
on how to use `terraform-bundle`, see
[the README from the v0.15 branch](https://github.com/hashicorp/terraform/blob/v0.15/tools/terraform-bundle/README.md).
[the README from the v0.15 branch](https://github.com/opentffoundation/opentf/blob/v0.15/tools/terraform-bundle/README.md).
You can follow a similar principle to build a `terraform-bundle` release
compatible with OpenTF v0.12 by using `--branch=v0.12` instead of
@@ -57,4 +57,4 @@ Terraform Cloud, you can use `terraform-bundle` as described above to build
custom OpenTF packages with bundled provider plugins.
For more information, see
[Installing a Bundle in Terraform Enterprise](https://github.com/hashicorp/terraform/blob/v0.15/tools/terraform-bundle/README.md#installing-a-bundle-in-terraform-enterprise).
[Installing a Bundle in Terraform Enterprise](https://github.com/opentffoundation/opentf/blob/v0.15/tools/terraform-bundle/README.md#installing-a-bundle-in-terraform-enterprise).

4
website/README.md
View File

@@ -55,7 +55,7 @@ You should preview all of your changes locally before creating a pull request. T
**Launch Site Locally**
1. Navigate into your local `terraform` top-level directory and run `make website`.
1. Navigate into your local `opentf` top-level directory and run `make website`.
1. Open `http://localhost:3000` in your web browser. While the preview is running, you can edit pages and Next.js automatically rebuilds them.
1. Press `ctrl-C` in your terminal to stop the server and end the preview.
@@ -63,7 +63,7 @@ You should preview all of your changes locally before creating a pull request. T
Merging a PR to `main` queues up documentation changes for the next minor product release. Your changes are not immediately available on the website.
The website generates versioned documentation by pointing to the HEAD of the release branch for that version. For example, the `v1.2.x` documentation on the website points to the HEAD of the `v1.2` release branch in the `terraform` repository. To update existing documentation versions, you must also backport your changes to that release branch. Backported changes become live on the site within one hour.
The website generates versioned documentation by pointing to the HEAD of the release branch for that version. For example, the `v1.2.x` documentation on the website points to the HEAD of the `v1.2` release branch in the `opentf` repository. To update existing documentation versions, you must also backport your changes to that release branch. Backported changes become live on the site within one hour.
### Backporting