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.
  1. 17 Jun, 2022 1 commit
    • Martin Atkins's avatar
      Experiments supported only in alpha/dev builds · fda05795
      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 in most release builds.
      
      The intent (not yet implemented in this PR) is for our release process to
      set this flag only when it knows it's building an alpha release or a
      development snapshot not destined for release at all, which will therefore
      allow us to still use the alpha releases as a vehicle for giving feedback
      participants access to a feature (without needing to install a Go
      toolchain) but will not encourage pretending that these features are
      production-ready before they graduate from experimental.
      
      Only language experiments have an explicit framework for dealing with them
      which outlives any particular experiment, so most of the changes here are
      to that generalized mechanism. However, the intent is that non-language
      experiments, such as experimental CLI commands, would also in future
      check Meta.AllowExperimentalFeatures and gate the use of those experiments
      too, so that we can be consistent that experimental features will never
      be available unless you explicitly choose to use an alpha release or
      a custom build from source code.
      
      Since there are already some experiments active at the time of this commit
      which were not previously subject to this restriction, we'll pragmatically
      leave those as exceptions that will remain generally available for now,
      and so this new approach will apply only to new experiments started in the
      future. Once those experiments have all concluded, we will be left with
      no more exceptions unless we explicitly choose to make an exception for
      some reason we've not imagined yet.
      
      It's important that we be able to write tests that rely on experiments
      either being available or not being available, so here we're using our
      typical approach of making "package main" deal with the global setting
      that applies to Terraform CLI executables while making the layers below
      all support fine-grain selection of this behavior so that tests with
      different needs can run concurrently without trampling on one another.
      
      As a compromise, the integration tests in the terraform package will
      run with experiments enabled _by default_ since we commonly need to
      exercise experiments in those tests, but they can selectively opt-out
      if they need to by overriding the loader setting back to false again.
      fda05795
  2. 28 Jan, 2022 1 commit
    • Martin Atkins's avatar
      configs: Decode preconditions and postconditions · 90764004
      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.
      90764004
  3. 29 Oct, 2021 1 commit
  4. 01 Jul, 2021 1 commit
    • Martin Atkins's avatar
      configs: Include "moved" blocks when merging multiple files into a module · 6b8e103d
      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.
      6b8e103d
  5. 21 Jun, 2021 1 commit
    • Kristin Laemmert's avatar
      configs: add decodeMovedBlock behind a locked gate. (#28973) · 3acb5e28
      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).
      3acb5e28
  6. 17 May, 2021 1 commit
    • Martin Atkins's avatar
      Move configs/ to internal/configs/ · 31349a9c
      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.
      31349a9c
  7. 26 Feb, 2021 1 commit
    • Martin Atkins's avatar
      configs: Accept and minimally validate a "language" argument · b5adc330
      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.
      b5adc330
  8. 24 Apr, 2020 1 commit
    • Alisdair McDiarmid's avatar
      configs: Simplify required_providers blocks · 7ca7b1f0
      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.
      7ca7b1f0
  9. 06 Apr, 2020 1 commit
    • Martin Atkins's avatar
      configs: Hint for a misplaced top-level required_providers block · 3e3d8f67
      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.
      3e3d8f67
  10. 06 Mar, 2020 1 commit
    • Paddy's avatar
      Add support for provider metadata to modules. (#22583) · e6592dc7
      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: default avatarPaul Tyng <paul@paultyng.net>
      e6592dc7
  11. 13 Jan, 2020 1 commit
    • Kristin Laemmert's avatar
      configs: extend module.ProviderRequirements to include the addrs.Provider... · 272cb44d
      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.
      272cb44d
  12. 10 Dec, 2019 1 commit
    • Martin Atkins's avatar
      experiments: a mechanism for opt-in experimental language features · b90fb253
      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 here is:
      
      - Recognize a new "experiments" setting in the "terraform" block which
        allows module authors to explicitly opt in to experimental features.
      
        terraform {
          experiments = [resource_for_each]
        }
      
      - Generate a warning whenever loading a module that has experiments
        enabled, to avoid accidentally depending on experimental features and
        thus risking unexpected breakage on next Terraform upgrade.
      
      - We check the enabled experiments against the configuration at module
        load time, which means that experiments are scoped to a particular
        module. Enabling an experiment in one module does not automatically
        enable it in any other module.
      
      This experiments mechanism is itself an experiment, and so I'd like to
      use the resource for_each feature to trial it. Because any configuration
      using experiments is subject to breaking changes, we are free to adjust
      this experiments feature in future releases as we see fit, but once
      for_each is shipped without an experiment gate we'll be blocked from
      making significant changes to it until the next major release at least.
      b90fb253
  13. 02 Oct, 2019 1 commit
    • Martin Atkins's avatar
      vendor: switch to HCL 2.0 in the HCL repository · 39e609d5
      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.
      39e609d5
  14. 09 Mar, 2018 1 commit
    • Martin Atkins's avatar
      configs: allow full type constraints for variables · 5661ab59
      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 like:
      
          {
            "variable": {
              "foo": {
                "type": "map(string)"
              }
            }
          }
      
      The selection of literal processing or HCL parsing of CLI-set values is
      now explicit in the model and separate from the type, though it's still
      derived from the type constraint and thus not directly controllable in
      configuration.
      
      Since this syntax is more complex than the keywords that replaced it, for
      now the simpler keywords are still supported and "list" and "map" are
      interpreted as list(any) and map(any) respectively, mimicking how they
      were interpreted by Terraform 0.11 and earlier. For the time being our
      documentation should continue to recommend these shorthand versions until
      we gain more experience with the more-specific type constraints; most
      users should just make use of the additional primitive type constraints
      this enables: bool and number.
      
      As a result of these more-complete type constraints, we can now type-check
      the default value at config load time, which has the nice side-effect of
      allowing us to produce a tailored error message if an override file
      produces an invalid situation; previously the result was rather confusing
      because the error message referred to the original definition of the
      variable and not the overridden parts.
      5661ab59
  15. 15 Feb, 2018 2 commits
    • Martin Atkins's avatar
      configs: allow overrides files to omit args that primary files can't · 7c8efe10
      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.
      7c8efe10
    • Martin Atkins's avatar
      configs: Parser.LoadConfigFile · e15ec486
      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.
      e15ec486