66 Commits (2cc94b4e89ccd47475c2b894e7cb9bd758ae73fc)

Author	SHA1	Message	Date
Liam Cervante	4ce385a19b	testing framework: implement overrides in terraform graph (#34169) ... * testing framework: implement overrides in terraform graph * fix bug for modules and module instances * add test for ModuleInstance.ContainingModule()	2 years ago
Liam Cervante	05f877166d	terraform test: parse mocking structures with test files (#34143)	3 years ago
Liam Cervante	8912396504	Reserve state and plan keywords in test files (#33846)	3 years ago
CJ Horton	98b81d3c50	add missing copyright headers	3 years ago
Liam Cervante	9742f22c4e	Introduce 'run' keyword for referencing outputs from earlier run blocks (#33683) ... * introduce 'run' keyword for referencing outputs from earlier run blocks * fix code consistency	3 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
Liam Cervante	c9bc7e8479	Add input validation into the 'checks' outputs and tracking (#33481)	3 years ago
Liam Cervante	f74a8d16cf	[testing framework] implement expect_failures functionality (#33443)	3 years ago
Liam Cervante	212ae6c4ba	Introduce separate testing scope for reference validation (#33339)	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Liam Cervante	87c457781d	Checks: Refactor existing check addrs and add new check block addr (#32733) ... * Add support for scoped resources * refactor existing checks addrs and add check block addr * address comments	3 years ago
Liam Cervante	d212a72d1d	structured run output: impose canonical ordering on jsonstate and jsonplan packages (#32649)	3 years ago
fatahfattah	8a31f0a6c8	addrs: ModuleSourceRemote.String correctly handles query string in URL ... Previously it would append the "subdir" portion onto the query string, producing an invalid result.	4 years ago
Martin Atkins	0e4e9f7706	addrs: Be explicit about checkable object address kinds ... 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.	4 years ago
Martin Atkins	3785619f93	core: Use the new checks package for condition tracking ... 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.	4 years ago
Martin Atkins	9dea19807f	checks: A new package for modeling custom condition checks ... 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.	4 years ago
Martin Atkins	696b403bf3	addrs: OutputValue.InModule ... Similar to other address types, this wraps the receiver up in its associated "config" type, binding it to a particular not-yet-expanded module.	4 years ago
Martin Atkins	d06cbfe6c8	addrs: ConfigCheckable type ... 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.	4 years ago
Martin Atkins	783a07d9e8	build: Use Go 1.19 ... Go 1.19's "fmt" has some awareness of the new doc comment formatting conventions and adjusts the presentation of the source comments to make it clearer how godoc would interpret them. Therefore this commit includes various updates made by "go fmt" to acheve that. In line with our usual convention that we make stylistic/grammar/spelling tweaks typically only when we're "in the area" changing something else anyway, I also took this opportunity to review most of the comments that this updated to see if there were any other opportunities to improve them.	4 years ago
kmoe	56a1e0d1c6	allow cross-package move statements (#31556)	4 years ago
Radek Simko	7feef1c4aa	Use hashicorp/terraform-registry-address as a decoupled library (#28338) ... * refactor: Use tfaddr for provider address parsing * refactor: Use tfaddr for module address parsing * deps: introduce hashicorp/terraform-registry-address	4 years ago
Martin Atkins	de8eef1da5	addrs: Format string instance keys in an HCL-compatible way ... So far we've only ever needed to re-parse address strings that happen not to contain instance keys and so we've gotten away with our serialization of these not being quite right, but given how liberally we've expected to be able to use address strings from this package for wire format interchange it seems likely that this is going to surprise us eventually. Now we'll use an escaping scheme compatible with HCL's parser rather than Go's parser, and so we can safely rely on hclsyntax.ParseTraversal as part of reversing this operation to transform an address string back into an address equivalent to the value it was created from.	4 years ago
Alisdair McDiarmid	ad52076025	addrs: Add tests for Module.String	4 years ago
Dennis Gursky	2c1b1f3aa1	Update module.go ... making code more similar to https://github.com/hashicorp/terraform/blob/main/internal/addrs/module_instance.go	4 years ago
Denny Gursky	8a694e81ff	string builder speed up for Module.String()	4 years ago
Martin Atkins	dc5964f8a3	refactoring: Use addrs.Map for maps with addresses as keys ... We introduced the addrs.UniqueKey and addrs.UniqueKeyer mechanics as part of implementing the ValidateMoves and ApplyMoves functions, as a way to better encapsulate the solution to the problem that lots of our address types aren't comparable and so cannot be used directly as map keys. However, exposing addrs.UniqueKey handling directly in the logic adds various noise to the algorithms and, in particular, obscures the fact that MoveResults.Changes and MoveResult.Blocked both have different map key types. Here then we'll use the new addrs.Map helper type, which encapsulates the idea of a map from an addrs.UniqueKeyer type to an arbitrary value type, using the unique keys as the map keys internally. This does unfortunately mean that we lose the conventional Go map access syntax and have to use a method-based API instead, but I (subjectively) think that's an okay compromise in return for avoiding the need to keep track inline of which addrs.UniqueKey values correspond with which real addresses. This is intended as an entirely-mechanical change, with equivalent behavior to what it replaced. If anything here is doing something materially different than what it replaced then that's a mistake.	4 years ago
Martin Atkins	eb2374070f	addrs: Generic types for maps and sets of addresses ... The addrs.Set type previously snuck in accidentally as part of the work to add addrs.UniqueKey and addrs.UniqueKeyer, because without support for generic types the addrs.Set type was a bit of a safety hazard due to not being able to enforce particular address types at compile time. However, with Go 1.18 adding support for type parameters we can now turn addrs.Set into a generic type over any specific addrs.UniqueKeyer type, and complement it with an addrs.Map type which supports addrs.UniqueKeyer keys as a way to encapsulate the handling of maps with UniqueKey keys that we currently do inline in various other parts of Terraform. This doesn't yet introduce any callers of these types, but we'll convert existing users of addrs.UniqueKeyer gradually in subsequent commits.	4 years ago
Alisdair McDiarmid	c5d10bdef1	core: Store condition block results in plan ... In order to include condition block results in the JSON plan output, we must store them in the plan and its serialization. Terraform can evaluate condition blocks multiple times, so we must be able to update the result. Accordingly, the plan.Conditions object is a map with keys representing the condition block's address. Condition blocks are not referenceable in any other context, so this address form cannot be used anywhere in the configuration. The commit includes a new test case for the JSON output of a refresh-only plan, which is currently the only way for a failing condition result to be rendered through this path.	4 years ago
Martin Atkins	2453025a1a	addrs: Reference.DisplayString method ... We've ended up implementing something approximately like this in a few places now, so this is a centralized version that we can consolidate on moving forward, gradually removing that duplication.	4 years ago
James Bardin	75ef61c783	check for nested module index changes ... Changing only the index on a nested module will cause all nested moves to create cycles, since their full addresses will match both the From and To addresses. When building the dependency graph, check if the parent is only changing the index of the containing module, and prevent the backwards edge for the move.	4 years ago
James Bardin	346418e31f	IsModuleMoveReIndex ... Add a method for checking if the From and To addresses in a move statement are only changing the indexes of modules relative to the statement module. This is needed because move statement nested within the module will be able to match against both the From and To addresses, causing cycles in the order of move operations.	4 years ago
Martin Atkins	affe2c3295	addrs: Expose the registry address parser's error messages ... Previously we ended up losing all of the error message detail produced by the registry address parser, because we treated any registry address failure as cause to parse the address as a go-getter-style remote address instead. That led to terrible feedback in the situation where the user _was_ trying to write a module address but it was invalid in some way. Although we can't really tighten this up in the default case due to our compatibility promises, it's never been valid to use the "version" argument with anything other than a registry address and so as a compromise here we'll use the presence of "version" as a heuristic for user intent to parse the source address as a registry address, and thus we can return a registry-address-specific error message in that case and thus give more direct feedback about what was wrong. This unfortunately won't help someone trying to install from the registry _without_ a version constraint, but I didn't want to let perfect be the enemy of the good here, particularly since we recommend using version constraints with registry modules anyway; indeed, that's one of the main benefits of using a registry rather than a remote source directly.	4 years ago
Katy Moe	aeecc6a627	add AffectedAbsResource to interface	4 years ago
Katy Moe	11566b1d11	introduce AbsMoveableResource ... AbsMoveableResource is an AbsMoveable that is either a resource or a resource instance. This interface represents a moveable that has a resource type.	4 years ago
Katy Moe	4305271cff	remove occurrences of AbsMovable	4 years ago
Martin Atkins	d054102d38	addrs: AbsResource.UniqueKey distinct from AbsResourceInstance.UniqueKey ... The whole point of UniqueKey is to deal with the fact that we have some distinct address types which have an identical string representation, but unfortunately that fact caused us to not notice that we'd incorrectly made AbsResource.UniqueKey return a no-key instance UniqueKey instead of its own distinct unique key type.	5 years ago
Martin Atkins	ef5a1c9cfe	refactoring: ImpliedMoveStatements function ... This new function complements the existing function FindMoveStatements by potentially generating additional "implied" move statements that aren't written explicit in the configuration but that we'll infer by comparing the configuration and te previous run state. The goal here is to infer only enough to replicate the effect of the "count boundary fixup" graph node (terraform.NodeCountBoundary) that we currently use to deal with this concern of preserving the zero-instance when switching between "count" and not "count". This is just dead code for now. A subsequent commit will introduce this into the "terraform" package while also removing terraform.NodeCountBoundary, thus achieving the same effect as before but in a way that'll get reported in the UI as a move, using the same language that we'd use for an explicit move statement.	5 years ago
Martin Atkins	7f99a8802e	addrs: MoveEndpointInModule.SelectsResource ... This is similar to the existing SelectsModule method, returning true if the reciever selects either a particular resource as a whole or any of the instances of that resource. We don't need this test in the normal case, but we will need it in a subsequent commit when we'll be possibly generating _implied_ move statements between instances of resources, but only if there aren't explicit move statements mentioning those resources already.	5 years ago
James Bardin	863963e7a6	de-linting	5 years ago
James Bardin	bc60f7aae4	Extend CanChainFrom to handle relative modules ... CanChainFrom needs to be able to handle move statements from different relative modules, re-implementing with addrs.anyKey Add the anyKey InstanceKey value to the addrs package to simplify module path comparison. This allows all combinations of module path representation to be normalized into a ModuleInstance which can be compared directly, rather than dealing with multiple levels of different prefix types.	5 years ago
James Bardin	2dff0481c8	missed relMatch for AbsModuleCall in SelectsModule	5 years ago
James Bardin	6087b1bdb9	CanChainFrom and NestedWithin ... Add implementations of CanChainFrom and NestedWithin for MoveEndpointInModule. CanChainFrom allows the linking of move statements of the same address, which means the prior destination address must equal the following source address. If the destination and source addresses are of different types, they must be covered by NestedWithin rather than CanChainFrom. NestedWithin checks if the destination contains the source address. Any matching types would be covered by CanChainFrom.	5 years ago
James Bardin	88ad938cc6	Equal methods for move AbsMoveable ... Make sure all the types are comparable	5 years ago
Martin Atkins	aa414f3ab3	refactoring: First round of ValidateMoves rules ... This is a first pass at implementing refactoring.ValidateMoves, covering the main validation rules. This is not yet complete. A couple situations not yet covered are represented by commented test cases in TestValidateMoves, although that isn't necessarily comprehensive. We'll do a further pass of filling this out with any other subtleties before we ship this feature.	5 years ago
Martin Atkins	ae2c93f255	addrs: All AbsMovable implementations implement UniqueKeyer	5 years ago
Martin Atkins	57d36c1d9d	addrs: ModuleInstance.ChildCall method ... This allows us to concisely construct AbsModuleCall address values by method chaining from module instance addresses.	5 years ago
Martin Atkins	5a6d11e375	addrs: Factor out MoveEndpointInModule module prefix matching ... All of our MoveDestination methods have the common problem of deciding whether the receiver is even potentially in the scope of a particular MoveEndpointInModule, which requires that the receiver belong to an instance of the module where the move statement was found. Previously we had this logic inline in all three cases, but now we'll factor it out into a shared helper function. At first it seemed like there ought to be more factoring possible for the AbsResource vs. AbsResourceInstance implementations, since textually they look very similar, but in practice they only look similar because those two types have a lot of method names in common, but the Go compiler sees them as completely distinct and thus we must write the same logic out twice. I did try some further refactoring to address that but it made the resulting code significantly more complicated and, by my judgement, harder to follow. Consequently I decided that a little duplication was okay and warranted here because this logic is already quite fiddly to read through and isn't likely to change significantly once released (due to backward-compatibility promises).	5 years ago
Martin Atkins	45d16b4a2b	addrs: MoveDestination for AbsResourceInstance-based move endpoints ... Previously our MoveDestination methods only honored move statements whose endpoints were module calls, module instances, or resources. Now we'll additionally handle when the endpoints are individual resource instances. This situation only applies to AbsResourceInstance.MoveDestination because no other objects can be contained inside of a resource instance. This completes all of the MoveDestination cases for all supported move statement types and moveable object types.	5 years ago
Martin Atkins	5e86bab159	addrs: MoveDestination for AbsResource-based move endpoints ... Previously our MoveDestination methods only honored move statements whose endpoints were module calls or module instances. Now we'll additionally handle when the endpoints are whole resource addresses. This includes both renaming resource blocks and moving resource blocks into or out of child modules. This doesn't yet include endpoints that are specific resource _instances_, which will follow in a subsequent commit. For the moment that situation will always indicate a non-match.	5 years ago
Martin Atkins	994ee23c06	addrs: Module move support for AbsResource and AbsResourceInstance ... This is a subset of the MoveDestination behavior for AbsResource and AbsResourceInstance which deals with source and destination addresses that refer to module calls or module instances. They both work by delegating to ModuleInstance.MoveDestination and then applying the same resource or resource instance address to the newly-chosen module instance address, thus ensuring that when we move a module we also move all of the resources inside that module in the same way. This doesn't yet include support for moving between specific resource or resource instance addresses; that'll follow later. This commit should have enough logic to support moving between module names and module instance keys, including any module calls or resources nested within.	5 years ago