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. 31 Aug, 2022 4 commits
  2. 30 Aug, 2022 8 commits
  3. 29 Aug, 2022 11 commits
  4. 26 Aug, 2022 17 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
    • Martin Atkins's avatar
      addrs: OutputValue.InModule · 696b403b
      Martin Atkins authored
      Similar to other address types, this wraps the receiver up in its
      associated "config" type, binding it to a particular not-yet-expanded
      module.
      696b403b
    • Martin Atkins's avatar
      configs: Variable and Output both have Addr methods · 209b8de7
      Martin Atkins authored
      We previously added methods like this for some of the other types in this
      package, including Local in this same file, but apparently haven't needed
      these two yet.
      209b8de7
    • Martin Atkins's avatar
      addrs: ConfigCheckable type · d06cbfe6
      Martin Atkins authored
      Our existing addrs.Checkable represents a particular (possibly-dynamic)
      object that can have checks associated with it.
      
      This new addrs.ConfigCheckable represents static configuration objects
      that can potentially generate addrs.Checkable objects.
      
      The idea here is to allow us to predict from the configuration a set of
      potential checkable object containers and then dynamically associate
      the dynamic checkable objects with them as we make progress with planning.
      
      This is intended for our integration of checks into the "terraform test"
      testing harness, to be used instead of the weirdo builtin provider we were
      using as a placeholder before we had first-class syntax for checks.
      Test reporting tools find it helpful for there to be a consistent set of
      test cases from one run to the next so that they can report on trends over
      multiple runs, and so our ConfigCheckable addresses will serve as the
      relatively-static "test case" that we'll then associate the dynamic checks
      with, so that we can still talk about objects in the test result report
      even if we end up not reaching them due to an upstream conditution failure.
      d06cbfe6
    • Megan Bang's avatar
      fix cloud state breaking? · 344379f5
      Megan Bang authored
      344379f5
    • Megan Bang's avatar
      update flow of schema checking · d5decc24
      Megan Bang authored
      d5decc24
    • Megan Bang's avatar
      check for cloud integration mode · 12e3560d
      Megan Bang authored
      12e3560d
    • Megan Bang's avatar
      updates to cloud state · 021f1f69
      Megan Bang authored
      021f1f69
    • Megan Bang's avatar
      update to warn if schemas aren't available · b8f2f81c
      Megan Bang authored
      b8f2f81c