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. 29 Sep, 2022 1 commit
  2. 28 Sep, 2022 1 commit
  3. 27 Sep, 2022 1 commit
  4. 26 Sep, 2022 7 commits
    • Martin Atkins's avatar
      core: Document that TransformRoot must produce coalescable node · cc964e6b
      Martin Atkins authored
      We use a non-pointer value for this particular node, which means that
      there can never be two root nodes in the same graph: the graph
      implementation will just coalesce them together when a second one is added.
      
      Our resource expansion code is relying on that coalescing so that it can
      subsume together multiple graphs for different modules instances into a
      single mega-graph with all instances across all module instances, with
      any root nodes coalescing together to produce a single root.
      
      This also updates one of the context tests that exercises resource
      expansion so that it will generate multiple resource instance nodes per
      module and thus potentially have multiple roots to coalesce together.
      However, we aren't currently explicitly validating the return values from
      DynamicExpand and so this test doesn't actually fail if the coalescing
      doesn't happen. We may choose to validate the DynamicExpand result in a
      later commit in order to make it more obvious if future modifications fail
      to uphold this invariant.
      cc964e6b
    • Martin Atkins's avatar
      core: Eliminate NodePlannableResource indirection · 2e177cd6
      Martin Atkins authored
      We previously did two levels of DynamicExpand to go from ConfigResource to
      AbsResource and then from AbsResource to AbsResourceInstance.
      
      We'll now do the full expansion from ConfigResource to AbsResourceInstance
      in a single DynamicExpand step inside nodeExpandPlannableResource.
      
      The new approach is essentially functionally equivalent to the old except
      that it fixes a bug in the previous implementation: we will now call
      checkState.ReportCheckableObjects only once for the entire set of
      instances for a particular resource, which is what the checkable objects
      infrastructure expects so that it can always mention all of the checkable
      objects in the check report even if we bail out partway through due to
      a downstream error.
      
      This is essentially the same code but now turned into additional methods
      on nodeExpandPlannableResource instead of having the extra graph node
      type. This has the further advantage of this now being straight-through
      code with standard control flow, instead of the unusual inversion of
      control we were doing before bouncing in and out of different Execute and
      DynamicExpand implementations to get this done.
      2e177cd6
    • Martin Atkins's avatar
      core: DynamicExpand can return diagnostics · a9bd4099
      Martin Atkins authored
      We were previously _trying_ to handle diagnostics here but were not quite
      doing it right because we were testing whether the resulting error was
      nil rather than appending it to the diagnostics and then seeing if the
      result has errors.
      
      The difference here is important because it allows DynamicExpand to return
      warnings without associated errors when needed. Previously the graph
      walker would treat a warnings-only result as if it were an error.
      
      Ideally we'd change DynamicExpand to return diagnostics directly, but we
      previously decided against that because there were so many implementors
      to update, and my intent for this change is to be surgical in the update
      so we minimize risk of backporting the change into patch releases.
      a9bd4099
    • James Bardin's avatar
      Merge pull request #31871 from hashicorp/jbardin/remove-planned-during-import · dbaf6d63
      James Bardin authored
      RemovePlannedResourceInstanceObjects during import
      dbaf6d63
    • James Bardin's avatar
      Merge pull request #31858 from hashicorp/jbardin/prune-plan-destroy · 008810f5
      James Bardin authored
      prune unused nodes from a destroy plan graph
      008810f5
    • James Bardin's avatar
      Merge pull request #31857 from hashicorp/jbardin/destroy-edge-cycles · 1c8352d9
      James Bardin authored
      prevent cycles when connecting destroy nodes
      1c8352d9
    • James Bardin's avatar
      prevent cycles when connecting destroy nodes · ce023445
      James Bardin authored
      When adding destroy edges between resources from different providers,
      and a provider itself depends on the other provider's resources, we can
      get cycles in the final dependency graph.
      
      The problem is a little deeper than simply not connecting these nodes,
      since the edges are still needed when doing a full destroy operation.
      For now we can get by assuming the edges are required, and reverting
      them only if they result in a cycle. This works because destroy edges
      are the last edges added to managed resources during graph building.
      
      This was rarely a problem before v1.3, because noop nodes were not added
      to the apply graph, and unused values were aggressively pruned. In v1.3
      however all nodes are kept in the graph so that postcondition blocks are
      always evaluated during apply, increasing the chances of the cycles
      appearing.
      ce023445
  5. 25 Sep, 2022 1 commit
    • James Bardin's avatar
      RemovePlannedResourceInstanceObjects during import · 5bca0c60
      James Bardin authored
      Because import uses the complete planning process, it must also call
      RemovePlannedResourceInstanceObjects. This is required to serialized the
      resulting state if there are data sources with an ObjectPlanned status
      because they could not be read during the import process.
      5bca0c60
  6. 23 Sep, 2022 11 commits
  7. 22 Sep, 2022 8 commits
  8. 21 Sep, 2022 3 commits
  9. 20 Sep, 2022 4 commits
  10. 19 Sep, 2022 3 commits