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 ...
      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...
      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 lik...
      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