9ddd3c1128
Before Go 1.21 we relied on third-party and custom tooling to manage which version of Go we were using for development, testing, and release builds. However, modern Go toolchains have built-in support for selecting an appropriate toolchain based on metadata in the go.mod file, and so we had previously removed most uses of the .go-version file and were maintaining it just as a remnant of the old state of things. This replaces our last remaining use of the ".go-version" file with a small tool that extracts the Go version from the go.mod file, and then removes the ".go-version" file completely. The "go" and "toolchain" directives in go.mod are now our single source of truth about which version of Go we're currently using for OpenTofu. (It may be possible to rework the Dockerfile for the consul backend to handle Go version selection in a different way so that we'd no longer need even this "selected-go-version" tool, but that's beyond the scope of this commit which aims to leave it unmodified to make sure the effective testing behavior for that backend is unchanged for now.) Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
OpenTofu Core Codebase Documentation
This directory contains some documentation about the OpenTofu Core codebase, aimed at readers who are interested in making code contributions.
If you're looking for information on using OpenTofu, please instead refer to the main OpenTofu CLI documentation.
OpenTofu Core Architecture Documents
-
OpenTofu Core Architecture Summary: an overview of the main components of OpenTofu Core and how they interact. This is the best starting point if you are diving in to this codebase for the first time.
-
Resource Instance Change Lifecycle: a description of the steps in validating, planning, and applying a change to a resource instance, from the perspective of the provider plugin RPC operations. This may be useful for understanding the various expectations OpenTofu enforces about provider behavior, either if you intend to make changes to those behaviors or if you are implementing a new OpenTofu plugin SDK and so wish to conform to them.
(If you are planning to write a new provider using the official SDK then please refer to the Extend documentation instead; it presents similar information from the perspective of the SDK API, rather than the plugin wire protocol.)
-
Diagnostics: how we report errors and warnings to end-users in OpenTofu.
-
Plugin Protocol: gRPC/protobuf definitions for the plugin wire protocol and information about its versioning strategy.
This documentation is for SDK developers, and is not necessary reading for those implementing a provider using the official SDK.
-
How OpenTofu Uses Unicode: an overview of the various features of OpenTofu that rely on Unicode and how to change those features to adopt new versions of Unicode.
Contribution Guides
- Contributing to OpenTofu: a complete guideline for those who want to contribute to this project.