terraform

Commit Graph

Author	SHA1	Message	Date
Brian Flad	1298fcd412	Add missing function deprecation_message to JSON output and website documentation (#34520 ) Reference: https://github.com/hashicorp/terraform/pull/34450	2 years ago
James Bardin	bc945f22eb	Merge pull request #34515 from hashicorp/jbardin/provider-function-validation Add validation for provider function results	2 years ago
James Bardin	5c7b6614f5	add Validate to providerFunctionImpurePlan test In normal operation a Validate always precedes Plan, so add a check for that phase in the Plan test.	2 years ago
James Bardin	a5337b3b20	remove global results table state In the case of now possible long-running terraform processes, we don't want the cache to grow indefinitely. Move the handling of the results into the terraform package, and inject the shared table during the walk into the `BuildFunction` wrapper.	2 years ago
Liam Cervante	0ca03ecf08	Extend refactoring package to support cross-provider moves (#34501 ) * Extend refactoring package to support cross-provider moves * implement provider cache * make generate	2 years ago
Liam Cervante	7d143388f3	Add support for the cross resource type move operation in the proto schema (#34480 ) * Update proto schema and provider interfaces with support for moved across resource type RPCs * address comments * remove unused functions * remove support for flatmap format	2 years ago
Liam Cervante	ce16e1a68a	Complete upgrade guide for v1.7 (#34514 ) * complete 1.7 upgrade guide * also call out state interoperability * Update website/docs/language/upgrade-guides/index.mdx Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com> * actually fix dangling v1.6 references --------- Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>	2 years ago
James Bardin	94d64364a4	test provider function consistency	2 years ago
James Bardin	a3aa517589	store and verify provider functions calls in plan Store the hashed function calls within the plan file, so that Terraform can validate the results during apply as well. The error won't be as good, since we don't have access to the prior results to help debugging, but it is very helpful to indicate when a function returned an incorrect result rather than show that the resource attempted to apply a different value from what was originally planned.	2 years ago
James Bardin	b3c5590f01	Merge pull request #34450 from hashicorp/jbardin/provider-functions-json-schema Add functions definitions to the `providers schema -json` output	2 years ago
James Bardin	2e74fec583	add optional Summary field to function json	2 years ago
Graham Davison	2dba4003c8	Merge pull request #34511 from hashicorp/s3/ignore-default-workspace-prefix-errors backend/s3: Ignore default workspace prefix errors	2 years ago
Graham Davison	bf4f36a3b7	tabs vs spaces	2 years ago
Graham Davison	0ff0ad8ce4	Updates documentation on IAM permissions with workspaces	2 years ago
Graham Davison	86da6ef19a	Adds section on storage locations	2 years ago
Graham Davison	02fadba041	Corrects path	2 years ago
Graham Davison	9d8ff095c0	Formatting	2 years ago
Graham Davison	57ec131e80	Ignores `AccessDenied` errors when listing bucket with default prefix	2 years ago
Graham Davison	40e593ddc1	Adds constant for default workspace prefix	2 years ago
Martin Atkins	3c14eeb945	stackeval: Make some provisioners available to stack components This makes the built-in "remote-exec" and "file" provisioners available for use in the modules that implement stack components. These are both relatively easy and low-risk to include because they are builtins and don't require anything from outside of Terraform itself. For now this intentionally excludes local-exec because we'll want to think about what constraints we want to put on it, if any, to help ensure we can meet the goal of stack configurations being portable between different execution environments without significant modification, and our current stacks execution environment doesn't guarantee the availability of any external software _at all_. The motivation for adding this now is just to give some better feedback when someone uses a module using one of these provisioners, since otherwise they'll see just a confusing generic error message from the modules runtime about the provisioners not being available. I expect we'll revisit this later and consider expanding it to at least include local-exec, and _maybe_ external provisioner plugins, although that's more questionable because the provisioner plugin mechanism is incredibly legacy and doesn't have any way to work outside of local Terraform CLI usage today. There are no tests here yet because these provisioners are not mockable and would depend on having an SSH or WinRM server to connect to. Later we should ponder how to make this more testable, which might mean making another part of the system responsible for actually providing the provisioner factories and thus our tests here can use fakes. The goal here is just to get this done in a relatively lightweight way for better feedback during preview though, so we're not yet ready to make significant time investments here.	2 years ago
Martin Atkins	6071e06f1a	tfstackdata1: DynamicValueFromTFStackData1 decodes sensitive marks	2 years ago
Alisdair McDiarmid	27552162ca	Merge pull request #34414 from hashicorp/alisdair/stacks-sensitive-component-outputs stacks: Support sensitive component outputs	2 years ago
Alisdair McDiarmid	1d3f863f2b	stackruntime: Support sensitive component inputs Components can emit sensitive values as outputs, which can be consumed as inputs to other components. This commit ensures that such values are correctly processed in order to pass their sensitivity to the modules runtime.	2 years ago
Alisdair McDiarmid	fc75657113	terraform: Support sensitive input variable values The stacks runtime interacts directly with the modules runtime's planning operations, rather than through the usual CLI paths. As a result, root module input variable values can be marked as sensitive upon entry. This commit adds support for such marked values to the modules runtime and the `plans.Plan` type. This is sufficient for stacks, which does not use the planfile serialization, but we may in future choose to serialize these decoded marks also.	2 years ago
Alisdair McDiarmid	e4b319401e	stacksruntime: Add sensitive outputs tests	2 years ago
Martin Atkins	3961c18420	stackeval: Return an error if a module contains a provider config When using stacks the provider configurations belong in the stack configuration rather than inline in the individual modules. Shared modules with inline provider configurations has been a deprecated legacy practice for many years now, but traditional Terraform continued to support it for backward-compatibility with older modules despite the significant downsides of doing so. Stacks now finally removes that capability, since it isn't straightforward to continue supporting it once we've made the stacks runtime be responsible for instantiating and configuring providers.	2 years ago
Martin Atkins	a51c034cc3	stackeval: Include component configurations in our static walks This means both that the validate walk can now describe static problems in the component's module tree, and that we'll catch such problems earlier in the planning phase and thus avoid reporting them repeatedly in cases where a component block uses for_each to declare multiple instances. This includes a fix to a bug in StackConfig.Components, which was incorrectly using the input variable declarations as the source for its result, instead of the component declarations.	2 years ago
Martin Atkins	a3cd4a11ce	stackeval: Use relative, slashy paths in module-related diagnostics Until we've updated the module config loader to be sourcebundle-aware and thus return proper source addresses, this will at least make the paths we show in diagnostics a little less verbose, and more consistent across platforms.	2 years ago
Martin Atkins	a4d61733f6	stackplan: Include extra info in raw component instance plan We'll now track the planned action, the component addresses we depend on, and the planned output values.	2 years ago
Martin Atkins	25a514f846	stackeval: Populate planned component instance more thoroughly We'll now track a more realistic Action, the components that the component instance depends on, and the planned output values.	2 years ago
Martin Atkins	524da4f278	stackeval: Applyable objects have a set of required components To figure out the required order in which we'll apply the plans for all components we need to know how data flows between them. We'll use what's added here during the plan phase to record in the plan which components depend on which other components, and then the apply phase will use that coarse information to schedule the individual component apply operations into a suitable order. None of that is implemented here though, and will follow in future commits. This commit includes new documentation about the apply scheduling approach which includes some mechanisms that are not actually yet included in this commit, but will follow shortly after. This is just a pragmatic compromise to avoid spending time authoring short-lived partial documentation drafts for the intermediate steps while still keeping these increments small enough for practical review.	2 years ago
Martin Atkins	5bfdb12098	stackaddrs: Absolute references and referenceables This allows us to talk about references between expressions in absolute terms, taking into account the stack where a particular expression would be resolved. This isn't an appropriate representation for references like each.key, since those require a more specific scope than just a stack, but that's okay because those contextual reference types can't depend on anything other than what they are embedded inside anyway, and so we never need to consider them when we're doing global reference analysis.	2 years ago
Martin Atkins	00761a9f70	stackeval: ApplyChecker is now Applyable We chose this name originally to communicate that implementations are only responsible for checking that an apply was successful, but in future commits this interface will also gain the additional responsibility of helping to gather the information required to understand the dependency relationships between components that will then drive the scheduling of the apply actions during the apply phase.	2 years ago
Martin Atkins	11bb10ba72	stackeval: Find references in arbitrary expressions and bodies Along with full expression/body evaluation, we'll also need to be able to determine what an expression or body refers to without evaluating it, so that we can use references to infer dependency relationships between significant side-effects in the apply phase, such as the relative ordering of applying the changes for different components.	2 years ago
Martin Atkins	8cb51f415b	collections: go-cmp helpers for the collection types A downside of using custom collection types is that go-cmp doesn't support them automatically, and so we need to help it out a little by providing additional options. An additional awkwardness is that go-cmp does all of its work at runtime using reflection, at which point the generic types have all been erased and lowered to many separate concrete types. Therefore we need some helper functions to produce a dynamically representation using interface types, cautiously exposing some internal details of these types only for go-cmp's use. The dynamic adapter here unfortunately means that the compiler likely won't be able to optimize away CmpOptions in non-test builds, but we'll accept that for now since the cost of that inert data and code is relatively small. If it turns out to be a problem then we'll need to find a different strategy, but hopefully not.	2 years ago
Martin Atkins	306b9008c4	stackeval: Clean some debug junk in ComponentInstance I apparently missed this when I was preparing my previous round of commits in this area. Mea culpa.	2 years ago
dependabot[bot]	38119217d9	build(deps): bump github.com/cloudflare/circl from 1.3.3 to 1.3.7 (#34504 ) Bumps [github.com/cloudflare/circl](https://github.com/cloudflare/circl) from 1.3.3 to 1.3.7. - [Release notes](https://github.com/cloudflare/circl/releases) - [Commits](https://github.com/cloudflare/circl/compare/v1.3.3...v1.3.7) --- updated-dependencies: - dependency-name: github.com/cloudflare/circl dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>	2 years ago
Liam Cervante	d2502265dc	removed: child modules should be removed if they are within a removed module (#34487 )	2 years ago
Nick Fagerlund	9d7737b2fe	Merge pull request #34447 from hashicorp/nf/dec23-grpc-metadata-cloudplugin Cloudplugin: Pass configuration via gRPC metadata	2 years ago
Nick Fagerlund	ff62192819	Adjust CloudPluginConfig doc comments	2 years ago
James Bardin	d94a61735e	Merge pull request #34472 from hashicorp/jbardin/schema-filter-attrs `Block.Filter` can panic with a nested object which has no attributes	2 years ago
Liam Cervante	7e18b1183d	Add test verifying issue #34476 has been fixed (#34478 )	2 years ago
James Bardin	f624437174	Merge pull request #34426 from hashicorp/dependabot/go_modules/golang.org/x/crypto-0.17.0 build(deps): bump golang.org/x/crypto from 0.16.0 to 0.17.0	2 years ago
Liam Cervante	bd40c411f7	Override provider schemas for mocked providers (#34481 ) * Override provider schemas for mocked providers * address comments	2 years ago
Nick Fagerlund	1a492b9dbb	Add test for (CloudPluginConfig).ToMetadata()	2 years ago
Nick Fagerlund	c398d0340f	Catch a missing assign-after-append I believe this is a slice append under the hood, which would mean `.Append()` consumes the original receiver and you shouldn't touch it afterwards.	2 years ago
Nick Fagerlund	7a1c49c61d	Append cloud plugin config metadata in plugin client requests - The cloud plugin wants a go-tfe client to get stuff from TFC. - Terraform knows how to find all the info you need in order to configure a go-tfe client, but it's sometimes scattered across configs and env vars and credentials helpers, and trying to re-implement the resolution logic identically in another codebase would be error-prone. - Therefore, it'd be best if Terraform did that resolution and just passed the plugin all the config info it needs. There are two options for that handoff: 1. Adding it as an additional argument to the primary Execute RPC interface. 2. Passing it as gRPC metadata, which is a pile of arbitrary key => list-of-strings pairs transmitted via HTTP/2 headers. The crux of the decision here is whether a proliferation of plugin protocol versions whenever we need to add more config data is better or worse than a fuzzy and typeless key/value bag. This PR is an implementation of option 2, for discussion and evaluation. (And after all, this is considered an experimental feature anyway.) It assembles the necessary information, translates it to the required metadata format, and attaches it to the request at the proper moment to get everything over to the plugin. As previous commits foreshadowed, we're leaning on the existing logic in the Cloud backend for pretty much all of this.	2 years ago
Nick Fagerlund	e1f0165693	Cloud command: Use cloud backend to find plugin config and service URLs The plugin needs some config info in order to actually build a go-tfe client and _do_ anything, and the Cloud backend is the one place that already knows how to look up and reconcile all the possible sources of that info. So, we'll just find a Cloud backend and pick its pockets. This also replaces our reimplementations of hostname lookup and service discovery, using work the Cloud backend already did.	2 years ago
Nick Fagerlund	c02533c889	Cloud backend: Cache service discovery in public ServicesHost field Most of the time, the Cloud backend is the only thing that needs to read the results of this discovery, and the only thing it cares about is the URL to the TFE v2 API service. However: - Other things might need to know about services that your TFC instance provides, including services other than the TFE v2 API. - There's a lot of complexity involved in determining which TFC instance you should be talking to (as well as the credentials for contacting it, the default org/workspace/project you're interested in, etc.), and it makes sense to leave the Cloud backend as the owner of that complexity rather than re-implement it in other potential consumers! So, since other TFC consumers will likely be configuring a Cloud backend to get their information anyway, might as well cache the known services so we don't have to repeat the discovery request. As part of this commit, note that I removed some code that swallowed a particular error during discovery. This was vestigial behavior that came over from the `remote` backend, but we were no longer performing the second part of the process (i.e. producing a more descriptive error in place of the one we swallowed). See https://github.com/hashicorp/terraform/pull/19659 for discussion about the original intent.	2 years ago
Nick Fagerlund	0248b6cf90	Give cloud TestRunner its own service discovery function I'm about to refactor the shared one away into a form it can't re-use. This is the only other callsite, so it can just own this logic.	2 years ago

1 2 3 4 5 ...

32188 Commits (1298fcd41259c2cf66306cce2453efd2c19f445d) All Branches Search

32188 Commits (1298fcd41259c2cf66306cce2453efd2c19f445d)

All Branches