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. 16 Aug, 2022 2 commits
  2. 29 Jul, 2022 1 commit
  3. 02 Sep, 2022 1 commit
    • Alisdair McDiarmid's avatar
      Merge pull request #31732 from... · 42ea0815
      Alisdair McDiarmid authored
      Merge pull request #31732 from hashicorp/backport/alisdair/typeexpr-upstreamed/annually-hopeful-filly
      
      Backport of Use upstreamed HCL typexpr package into v1.3
      42ea0815
  4. 01 Sep, 2022 2 commits
  5. 31 Aug, 2022 6 commits
  6. 30 Aug, 2022 8 commits
  7. 29 Aug, 2022 11 commits
  8. 26 Aug, 2022 9 commits
    • Martin Atkins's avatar
      command/jsonchecks: Mark check result objects as experimental · 71dec301
      Martin Atkins authored
      This is a clumsy way to do this, but a pragmatic way to inform potential
      consumers that this part of the format is not yet finalized without having
      to read the docs to see our warning about that.
      
      We need to get some practical experience with a few different consumers
      making use of this format before we can be confident that it's designed
      appropriately. We're not _expecting_ to break it, but we'd like to leave
      the opportunity open in case we quickly learn that there's something
      non-ideal about this design.
      71dec301
    • Martin Atkins's avatar
    • Martin Atkins's avatar
      addrs: Be explicit about checkable object address kinds · 0e4e9f77
      Martin Atkins authored
      Previously we were attempting to infer the checkable object address kind
      of a given address by whether it included "output" in the position where
      a resource type name would otherwise go.
      
      That was already potentially risky because we've historically not
      prevented a resource type named "output", and it's also a
      forward-compatibility hazard in case we introduce additional object kinds
      with entirely-new addressing schemes in future.
      
      Given that, we'll instead always be explicit about what kind of address
      we're storing in a wire or file format, so that we can make sure to always
      use the intended parser when reading an address back into memory, or
      return an error if we encounter a kind we're not familiar with.
      0e4e9f77
    • Martin Atkins's avatar
      command/jsonplan: Include new-style check results in JSON plan output · fe7e6f97
      Martin Atkins authored
      This is a new-shaped representation of check results which follows the
      two-tiered structure of static objects and dynamic instances of objects,
      thereby allowing consumers to see which checkable objects exist in the
      configuration even if a dynamic evaluation error prevented actually
      expanding them all to determine their declared instances.
      
      Eventually we'll include this in the state too, but this initially adds it
      only to the plan in order to replace the now-deprecated experimental
      conditions result that was present but undocumented in Terraform v1.2.
      fe7e6f97
    • Martin Atkins's avatar
      core: Propagate check results accurately from plan to apply · d63871f7
      Martin Atkins authored
      In an earlier commit we changed the states.CheckResults model to
      explicitly model the config object vs. dynamic checkable object hierarchy,
      but neglected to update the logic in Terraform Core to take that into
      account when propagating the object expansion decisions from the plan
      phase to the apply phase. That meant that we were incorrectly classifying
      zero-instance resources always as having an unknown number of instances,
      rather than possibly being known to have zero instances.
      
      This now follows the two-level heirarchy of the data structure, which has
      the nice side-effect that we can remove some of the special-case methods
      from checks.State that we were using to bulk-load data: the data is now
      shaped in the appropriate way to reload the data using the same method
      the plan phase would've used to record the results in the first place.
      d63871f7
    • Martin Atkins's avatar
      states/statefile: Serialize check results into state snapshots · 6de3b1bd
      Martin Atkins authored
      This allows us to retain check results from one run into the next, so that
      we can react to status changes between runs and potentially report e.g.
      that a previously-failing check has now been fixed, or that a
      previously-failing check is "still failing" so that an operator can get
      a hint as to whether a problem is something they've just introduced or if
      it was already an active problem before they made a change.
      6de3b1bd
    • Martin Atkins's avatar
      states: Two-level representation of check results · 9e4861ad
      Martin Atkins authored
      A significant goal of the design changes around checks in earlier commits
      (with the introduction of package "checks") was to allow us to
      differentiate between a configuration object that we didn't expand at all
      due to an upstream error, which has _unknown_ check status, and a
      configuration object that expanded to zero dynamic objects, which
      therefore has a _passing_ check status.
      
      However, our initial lowering of checks.State into states.CheckResults
      stayed with the older model of just recording each leaf check in isolation,
      without any tracking of the containers.
      
      This commit therefore lightly reworks our representation of check results
      in the state and plan with two main goals:
      - The results are grouped by the static configuration object they came
        from, and we capture an aggregate status for each of those so that
        we can differentiate an unknown aggregate result from a passing
        aggregate result which has zero dynamic associated objects.
      - The granularity of results is whole checkable objects rather than
        individual checks, because checkable objects have durable addresses
        between runs, but individual checks for an object are more of a
        syntactic convenience to make it easier for module authors to declare
        many independent conditions that each have their own error messages.
      
      Since v1.2 exposed some details of our checks model into the JSON plan
      output there are some unanswered questions here about how we can shift to
      reporting in the two-level heirarchy described above. For now I've
      preserved structural compatibility but not semantic compatibility: any
      parser that was written against that format should still function but will
      now see fewer results. We'll revisit this in a later commit and consider
      other structures and what to do about our compatibility constraint on the
      v1.2 structure.
      
      Otherwise though, this is an internal-only change which preserves all of
      the existing main behaviors of conditions as before, and just gets us
      ready to build user-facing features in terms of this new structure.
      9e4861ad
    • Martin Atkins's avatar
      core: Use the new checks package for condition tracking · 3785619f
      Martin Atkins authored
      The "checks" package is an expansion what we previously called
      plans.Conditions to accommodate a new requirement that we be able to track
      which checks we're expecting to run even if we don't actually get around
      to running them, which will be helpful when we start using checks as part
      of our module testing story because test reporting tools appreciate there
      being a relatively consistent set of test cases from one run to the next.
      
      So far this should be essentially a no-op change from an external
      functionality standpoint, aside from some minor adjustments to how we
      report some of the error and warning cases from condition evaluation in
      light of the fact that the "checks" package can now track errors as a
      different outcome than a failure of a valid check.
      
      As is often the case with anything which changes what we track
      in the EvalContext and persist between plan and apply, Terraform Core is
      pretty brittle and so this had knock-on effects elsewhere too. Again, the
      goal is for these changes to not create any material externally-visible
      difference, and just to accommodate the new assumption that there will
      always be a "checks" object available for tracking during a graph walk.
      3785619f
    • Martin Atkins's avatar
      checks: A new package for modeling custom condition checks · 9dea1980
      Martin Atkins authored
      The checks.Checks type aims to encapsulate keeping track of check results
      during a run and then reporting on them afterwards even if the run was
      aborted early for some reason.
      
      The intended model here is that each new run starts with an entirely fresh
      checks.Checks, with all of the statuses therefore initially unknown, and
      gradually populates the check results as we walk the graph in Terraform
      Core. This means that even if we don't complete the run due to an error
      or due to targeting options we'll still report anything we didn't visit
      yet as unknown.
      
      This commit only includes the modeling of checks in the checks package.
      For now this is just dead code, and we'll wire it in to Terraform Core in
      subsequent commits.
      9dea1980