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. 14 Jul, 2021 3 commits
  2. 13 Jul, 2021 3 commits
  3. 12 Jul, 2021 2 commits
  4. 09 Jul, 2021 3 commits
  5. 07 Jul, 2021 3 commits
  6. 06 Jul, 2021 2 commits
  7. 02 Jul, 2021 11 commits
  8. 01 Jul, 2021 13 commits
    • Laura Pacilio's avatar
      Merge pull request #29051 from hashicorp/add-page-metadata · dfc12a6a
      Laura Pacilio authored
      Add page metadata
      dfc12a6a
    • 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
    • Martin Atkins's avatar
      configs: valid-modules test ignores experimental features warning · d92b5e5f
      Martin Atkins authored
      A common source of churn when we're running experiments is that a module
      that would otherwise be valid ends up generating a warning merely because
      the experiment is active. That means we end up needing to shuffle the
      test files around if the feature ultimately graduates to stable.
      
      To reduce that churn in simple cases, we'll make an exception to disregard
      the "Experiment is active" warning for any experiment that a module has
      intentionally opted into, because those warnings are always expected and
      not a cause for concern.
      
      It's still possible to test those warnings explicitly using the
      testdata/warning-files directory, if needed.
      d92b5e5f
    • Martin Atkins's avatar
      configs: For Moved blocks, use addrs.MoveEndpoint instead of addrs.Target · 708003b0
      Martin Atkins authored
      Although addrs.Target can in principle capture the information we need to
      represent move endpoints, it's semantically confusing because
      addrs.Targetable uses addrs.Abs... types which are typically for absolute
      addresses, but we were using them for relative addresses here.
      
      We now have specialized address types for representing moves and probably
      other things which have similar requirements later on. These types
      largely communicate the same information in the end, but aim to do so in
      a way that's explicit about which addresses are relative and which are
      absolute, to make it less likely that we'd inadvertently misuse these
      addresses.
      708003b0
    • Martin Atkins's avatar
      addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint · 4cbe6cab
      Martin Atkins authored
      These three types represent the three different address representations we
      need to represent different stages of analysis for "moved" blocks in the
      configuration.
      
      The goal here is to encapsulate all of the static address wrangling inside
      these types so that users of these types elsewhere would have to work
      pretty hard to use them incorrectly.
      
      In particular, the MovableEndpoint type intentionally fully encapsulates
      the weird relative addresses we use in configuration so that code
      elsewhere in Terraform can never end up holding an address of a type that
      suggests absolute when it's actually relative. That situation only occurs
      in the internals of MoveableEndpoint where we use not-really-absolute
      AbsMoveable address types to represent the not-yet-resolved relative
      addresses.
      
      This only takes care of the static address wrangling. There's lots of
      other rules for what makes a "moved" block valid which will need to be
      checked elsewhere because they require more context than just the content
      of the address itself.
      4cbe6cab
    • Martin Atkins's avatar
      addrs: AbsModuleCall type · 3212f6f3
      Martin Atkins authored
      Our documentation for ModuleCall originally asserted that we didn't need
      AbsModuleCall because ModuleInstance captured the same information, but
      when we added count and for_each for modules we introduced
      ModuleCallInstance to represent a reference to an instance of a local
      module call, and now _that_ is the type whose absolute equivalent is
      ModuleInstance.
      
      We previously had no absolute representation of the call itself, without
      any particular instance. That's what AbsModuleCall now represents,
      allowing us to be explicit about when we're talking about the module block
      vs. instances it declares, which is the same distinction represented by
      AbsResource vs. AbsResourceInstance.
      
      Just like with AbsResource and AbsResourceInstance though, there is
      syntactic ambiguity between a no-key call instance and a whole module call,
      and so some codepaths might accept both to start and then use other
      context to dynamically choose a particular interpretation, in which case
      this distinction becomes meaningful in representing the result of that
      decision.
      3212f6f3
    • Martin Atkins's avatar
      addrs: Rename AbsModuleCallOutput to ModuleCallInstanceOutput · ab350289
      Martin Atkins authored
      The previous name didn't fit with the naming scheme for addrs types:
      The "Abs" prefix typically means that it's an addrs.ModuleInstance
      combined with whatever type name appears after "Abs", but this is instead
      a ModuleCallOutput combined with an InstanceKey, albeit structured the
      other way around for convenience, and so the expected name for this would
      be the suffix "Instance".
      
      We don't have an "Abs" type corresponding with this one because it would
      represent no additional information than AbsOutputValue.
      ab350289
    • Laura Pacilio's avatar
      Update vs Cloudformation description · e6f12558
      Laura Pacilio authored
      e6f12558
    • Laura Pacilio's avatar
      Update vs pages to address PR comments · ab9b9a44
      Laura Pacilio authored
      ab9b9a44
    • Laura Pacilio's avatar
      Update use cases page for PR comments · 09c79994
      Laura Pacilio authored
      09c79994
    • Laura Pacilio's avatar
      04385bb9
    • Laura Pacilio's avatar
      Edit copy to address PR comments · a9e09a3e
      Laura Pacilio authored
      a9e09a3e
    • Sam Salisbury's avatar
      Merge pull request #29064 from hashicorp/darwin-arm64 · 2fdf8986
      Sam Salisbury authored
      Build darwin/arm64 (RELENG-650)
      2fdf8986