This project is mirrored from https://:*****@github.com/hashicorp/terraform.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
- 17 Jun, 2022 1 commit
-
-
Martin Atkins authored
We originally introduced the idea of language experiments as a way to get early feedback on not-yet-proven feature ideas, ideally as part of the initial exploration of the solution space rather than only after a solution has become relatively clear. Unfortunately, our tradeoff of making them available in normal releases behind an explicit opt-in in order to make it easier to participate in the feedback process had the unintended side-effect of making it feel okay to use experiments in production and endure the warnings they generate. This in turn has made us reluctant to make use of the experiments feature lest experiments become de-facto production features which we then feel compelled to preserve even though we aren't yet ready to graduate them to stable features. In an attempt to tweak that compromise, here we make the availability of experiments _at all_ a build-time flag which will not be set by default, and therefore experiments will not be available ...
-
- 28 Jan, 2022 1 commit
-
-
Martin Atkins authored
This allows precondition and postcondition checks to be declared for resources and output values as long as the preconditions_postconditions experiment is enabled. Terraform Core doesn't currently know anything about these features, so as of this commit declaring them does nothing at all.
-
- 29 Oct, 2021 1 commit
-
-
Chris Arcand authored
This is a replacement declaration for using Terraform Cloud as a remote backend, leaving the literal backend as an implementation detail and not a user-level concept.
-
- 01 Jul, 2021 1 commit
-
-
Martin Atkins authored
An earlier commit added logic to decode "moved" blocks and do static validation of them. Here we now include that result also in modules produced from those files, which we can then use in Terraform Core to actually implement the moves. This also places the feature behind an active experiment keyword called config_driven_move. For now activating this doesn't actually achieve anything except let you include moved blocks that Terraform will summarily ignore, but we'll expand the scope of this in later commits to eventually reach the point where it's really usable.
-
- 21 Jun, 2021 1 commit
-
-
Kristin Laemmert authored
This PR adds decoding for the upcoming "moved" blocks in configuration. This code is gated behind an experiment called EverythingIsAPlan, but the experiment is not registered as an active experiment, so it will never run (there is a test in place which will fail if the experiment is ever registered). This also adds a new function to the Targetable interface, AddrType, to simplifying comparing two addrs.Targetable. There is some validation missing still: this does not (yet) descend into resources to see if the actual resource types are the same (I've put this off in part because we will eventually need the provider schema to verify aliased resources, so I suspect this validation will have to happen later on).
-
- 17 May, 2021 1 commit
-
-
Martin Atkins authored
This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
-
- 26 Feb, 2021 1 commit
-
-
Martin Atkins authored
We expect that in order to continue to evolve the language without breaking existing modules we will at some point need to have a way to mark when a particular module is expecting a newer interpretation of the language. Although it's too early to do any deep preparation for that, this commit aims to proactively reserve an argument named "language" inside "terraform" blocks, which currently only accepts the keyword TF2021 that is intended to represent "the edition of the Terraform language as defined in 2021". That argument also defaults to TF2021 if not set, so in practice there's no real reason to set this today, but this minimal validation today is intended to give better feedback to users of older Terraform versions in the event that we introduce a new language edition later and they try to use an module incompatible with their Terraform version.
-
- 24 Apr, 2020 1 commit
-
-
Alisdair McDiarmid authored
We now permit at most one `required_providers` block per module (except for overrides). This prevents users (and Terraform) from struggling to understand how to merge multiple `required_providers` configurations, with `version` and `source` attributes split across multiple blocks. Because only one `required_providers` block is permitted, there is no need to concatenate version constraints and resolve them. This allows us to simplify the structs used to represent provider requirements, aligning more closely with other structs in this package. This commit also fixes a semantic use-before-initialize bug, where resources defined before a `required_providers` block would be unable to use its source attribute. We achieve this by processing the module's `required_providers` configuration (and overrides) before resources. Overrides for `required_providers` work as before, replacing the entire block per provider.
-
- 06 Apr, 2020 1 commit
-
-
Martin Atkins authored
With provider dependencies now appearing inside a nested block, it seems likely that configuration examples showing dependencies out of context will sometimes mislead users into thinking that required_providers is toplevel. To give better feedback in that situation, we'll produce a specialized error in that case hinting the correct structure to the user.
-
- 06 Mar, 2020 1 commit
-
-
Paddy authored
Implement a new provider_meta block in the terraform block of modules, allowing provider-keyed metadata to be communicated from HCL to provider binaries. Bundled in this change for minimal protocol version bumping is the addition of markdown support for attribute descriptions and the ability to indicate when an attribute is deprecated, so this information can be shown in the schema dump. Co-authored-by:
Paul Tyng <paul@paultyng.net>
-
- 13 Jan, 2020 1 commit
-
-
Kristin Laemmert authored
configs: extend module.ProviderRequirements to include the addrs.Provider instead of just version constraints. (#23843) Renamed file.ProviderRequirements to file.RequiredProviders to match the name of the block in the configuration. file.RequiredProviders contains the contents of the file(s); module.ProviderRequirements contains the parsed and merged provider requirements. Extended decodeRequiredProvidersBlock to parse the new provider source syntax (version only, it will ignore any other attributes). Added some tests; swapped deep.Equal with cmp.Equal in the terraform/module_dependencies_test.go because deep was not catching incorrect constraints.
-
- 10 Dec, 2019 1 commit
-
-
Martin Atkins authored
Traditionally we've preferred to release new language features in major releases only, because we can then use the beta cycle to gather feedback on the feature and learn about any usability challenges or other situations we didn't consider during our design in time to make those changes before inclusion in a stable release. This "experiments" feature is intended to decouple the feedback cycle for new features from the major release rhythm, and thus allow us to release new features in minor releases by first releasing them as experimental for a minor release or two, adjust for any feedback gathered during that period, and then finally remove the experiment gate and enable the feature for everyone. The intended model here is that anything behind an experiment gate is subject to breaking changes even in patch releases, and so any module using these experimental features will be broken by a future Terraform upgrade. The behavior implemented...
-
- 02 Oct, 2019 1 commit
-
-
Martin Atkins authored
Previously we were using the experimental HCL 2 repository, but now we'll shift over to the v2 import path within the main HCL repository as part of actually releasing HCL 2.0 as stable. This is a mechanical search/replace to the new import paths. It also switches to the v2.0.0 release of HCL, which includes some new code that Terraform didn't previously have but should not change any behavior that matters for Terraform's purposes. For the moment the experimental HCL2 repository is still an indirect dependency via terraform-config-inspect, so it remains in our go.sum and vendor directories for the moment. Because terraform-config-inspect uses a much smaller subset of the HCL2 functionality, this does still manage to prune the vendor directory a little. A subsequent release of terraform-config-inspect should allow us to completely remove that old repository in a future commit.
-
- 09 Mar, 2018 1 commit
-
-
Martin Atkins authored
Previously we just ported over the simple "string", "list", and "map" type hint keywords from the old loader, which exist primarily as hints to the CLI for whether to treat -var=... arguments and environment variables as literal strings or as HCL expressions. However, we've been requested before to allow more specific constraints here because it's generally better UX for a type error to be detected within an expression in a calling "module" block rather than at some point deep inside a third-party module. To allow for more specific constraints, here we use the type constraint expression syntax defined as an extension within HCL, which uses the variable and function call syntaxes to represent types rather than values, like this: - string - number - bool - list(string) - list(any) - list(map(string)) - object({id=string,name=string}) In native HCL syntax this looks like: variable "foo" { type = map(string) } In JSON, this looks lik...
-
- 15 Feb, 2018 2 commits
-
-
Martin Atkins authored
Some of the fields in our config structs are either mandatory in primary files or there is a default value that we apply if absent. Unfortunately override files impose the additional constraint that we be allowed to omit required fields (which have presumably already been set in the primary files) and that we are able to distinguish between a default value and omitting a value entirely. Since most of our fields were already acceptable for override files, here we just add some new fields to deal with the few cases where special handling is required and a helper function to disable the "Required" flag on attributes in a given schema.
-
Martin Atkins authored
This is a first pass of decoding of the main Terraform configuration file format. It hasn't yet been tested with any real-world configurations, so it will need to be revised further as we test it more thoroughly.
-