* Pull `init` `Run` method into new method in a separate file, in preparation for adding experimental fork.
* Add license header
* Allow init args to be accessed before calling separate init run logic
* Add -enable-pss flag to the init command, to be used for accessing experimental init logic
* Fix- put call to `run` in else block!
* Make flag name more explicit
* Add an environment variable alternative to the CLI flag
* Make the panic text more user-friendly
* go fmt
* Allow backend or state_store config to be passed via BackendOpts from calling code
* Update messages sent to view: make message specific to state storage mechanism in use
* Add nil pointer check
* Fix typos
* Pivot to `Len` method approach of nil check
* Pivot to the point of pirouetting
* Store the FQN of the provider used in PSS in representations of the parsed config.
This can only be done once modules have been parsed and the required providers data is available. There are multiple places where config is parsed, into either Config or Module structs, so this needs to be implemented in multiple places.
* Update affected tests, improve error diagnostic
* Begin enabling method to return a backend.Backend made using state_store config.
State store config can now be received via BackendOpts and there is rough validation of whether the config makes sense (does the provider offer a store with the given name?).
* Update code's logic to include possibility of a state store being in use
At this point there are no cases that actually handle the state store scenarios though!
* Add empty cases for handle all broad init scenarios involving PSS
* Update default case's error to report state store variables
* Improve how we resolve the builtin terraform provider's address
* Add test that hits the code path for adding a state store to a new (or implied local) project
* Add test for use of `-reconfigure` flag; show that it hits the code path for adding a state store for the first time
* Add test that hits the code path for removing use of a state store, migrating to (implied) local backend
* Add test that hits the code path for changing a state store's configuration
* Update existing test names to be backend-specific
* Add tests that hits the code path for migrating between PSS and backends
* Consolidate PSS-related tests at end of the file
* Fix log text
* Add test showing that using variables is disallowed with state_store and nested provider blocks
* Update test name
* Fix test cases
* Add TODOs so we remember to remove experiments from tests
* Update state store-related tests to use t.Cleanup
* Remove use of `testChdir`
* Add actions to the plans and change
* jsonplan - ignoring LinkedResources for now, those are not in the MVP
* pausing here: we'll work on the plan rendering later
* Replace use of `testChdir` with `t.Chdir`
* Update tests to use temporary directories with copied content, instead of using directories in the repo directly.
* Remove stacks copy of testChdir function
This has been replaced with t.Chdir from the standard library
* Replace remaining simple usage of testChdir
* Update guidance for using `tempWorkingDir`
* Replace use of testChdir in a function reused in a single test
* Update comments to no longer recommend using testChdir
* Remove testChdir function!
* Add the ability to make a hash of state store config
* Add test demonstrating that the provider block doesn't impact the hash of a state_store block
* Make sure test asserts what would happen if the schema DID include the provider block
* Update the Hash method to return diagnostics, ignore nested provider blocks, and validate incoming schema and config
* Update tests to use more representative config, fix code under test as a result
* Update Hash method to return hashes for both the state_store and provider blocks
* Add test cases to cover how required fields are tolerated when making the hash
This is because ENVs may supply those values.
* Fix inaccurate comments
* Add test to show that hashes are consistent and exclude the provider block
* Update backend state file to contain hash of provider block's config
* Fix test to expect a hash for the provider config block.
* Fix bug in DeepCopy method, update test to have better error messages when diffs are detected
* Update test to explicitly check hash values
* Try make test intention clearer
* Improve user feedback when state store schema contains the protected word "provider"
* Update tests
* Update test to test the Hash method in a more true-to-life way
Copy of 04a1201878cd1f6f117c43c43c1ee9d0fc17cec1 by Radek Simko
* Update test to use new approach
* Fix `TestInit_stateStoreBlockIsExperimental` test failure
* Update comments to distinguish between operations and state-storage backends more clearly
* Rename `BackendOpts` field `Config` to more specific `BackendConfig`
* Add test coverage for Meta's determineInitReason method, fix error in diagnostic when migrating away from HCP Terraform
* Add godoc comment to determineInitReason method
* WIP
* Reuse plan command for query CLI
* Basic CLI output
* Only fail a list request on error
* poc: store query results in separate field
* WIP: odd mixture between JSONs
* Fix list references
* Separate JSON rendering
The structured JSON now only logs a status on which list query is
currently running. The new jsonlist package can marshal the query fields
of a plan.
* Remove matcher
* Store results in an extra struct
* Structured list result logging
* Move list result output into hooks
* Add help text and additional flag
* Disable query runs with the cloud backend for now
* Review feedback
* Implement `ForPlan` method on `StateStoreConfigState`, add `Planner` interface
* Rename `ForPlan` method to `Plan`
* Allow plan files to contain information about state stores
* Add code needed for representing a state store in the Plan struct, which is used when handling plan files
* Add ability to read/write either a backend or state store's data in a plan file. Add some test coverage.
* Update plan's `ProviderAddrs` method to include the provider used for PSS, if present
* Split interfaces
* Apply feedback from code review
* Refactor `SetVersion` to use appropriate constructor
* Split `ProviderAddrs` method test into two
* Fix method call after rename
* Fix test
* Remove change to `(p *Plan) ProviderAddrs()`
We may re-add this when we implement PSS for use during apply commands with plan files
* Remove changes to test, now that the plan doesn't report the provider used for PSS anymore.
* Add test showing that users cannot delete the default workspace
Note: in the test this validation is being returned from the local backend's `DeleteWorkspace` method, not the command itself.
* Make the `workspace delete` command return early if the user is trying to delete the default workspace. Update test.
* Clean up redundant parts of test
* Add tests defining what are valid workspace names
* Update workspace name validation to mark an empty string as not valid
* Add change file
* Add command-level test showing the "" workspace cannot be created or selected
* Update invalid name error text to include empty string as invalid.
* Split code for backend state file vs backend state
* Rename BackendState to BackendConfigState
* Spelling error
* Add `StateStorageConfigState` struct as new implementation of new `ConfigState[T any]` interface.
* Split tests for backend state file vs backend config state structs
* Rename StateStorageConfigState to StateStoreConfigState
* Clarify test name, add comments
* Add tests for StateStoreConfigState methods
* Add test showing state_store in JSON is parsed correctly
* Add detection of malformed backend state files that contain both backend and state_store fields
* Add validation that stops a backend state file being written if it will contain state for both backend and state_store blocks
* Rename `state_storage` to `state_store`
* Rename `state_storage` to `state_store` in filenames
* Move`ConfigState` to its own file
* Fix test name, remove whitespace
* Update `StateStoreConfigState` comment using review suggestion
* Update error message to no longer allude to the environment TF is being run in
* Update the state_store state to use `version.Version` and an adapted version of `tfaddr.Provider` for marshalling version and source data
* Update test helper so it doesn't accidentally supply validation in tests
* Add protection against saving an empty backend state file
* Remove direct testing of (s *Source) MarshalText() and UnmarshalText() methods
* Add Validate method to StateStoreConfigState, use in backend state encoding logic
* Refactor to use new features in registry dependency
* Enable parsing of blocks in individual files
Co-authored-by: Radek Simko <radeksimko@users.noreply.github.com>
* Enable handling of state stores when parsing a module from its constituent files.
This includes: validations of duplicates and clashes, supporting override files.
Co-authored-by: Radek Simko <radeksimko@users.noreply.github.com>
* Add tests for validation that detects conflicts between state_store blocks and others
* Add tests for state_store override behavior
* Add tests for validation that detects when conflicting state-related blocks are used, either in the same file or across separate files
* Update error message summaries to explicitly say blocks conflict
* Add small changes to assertions in state_store override tests
* Update state_store block parsing to expect scoped provider block
* Update tests following syntax change
* Make config parsing experimental
* Remove testModuleFromDirWithExperiment, as testModuleFromDirWithExperiments exists!
* Update code comment
---------
Co-authored-by: Radek Simko <radeksimko@users.noreply.github.com>
Co-authored-by: Radek Simko <radek.simko@gmail.com>
* terraform test: add variable definitions to test files
Currently, `terraform test` attempts to work out the type of any external variables by delaying evaluation until each run block executes so it can use the definitions within the run blocks's module. This means that the values of variables can technically change between run blocks which isn't ideal.
This commit is the first in a chain which will move the evaluation of variables into the terraform test graph. We need to give the users the option of specifying the type for external variables within the file as these variables are now going to be assessed outside of the context of a run block. To do this, we introduce the optional variable blocks that are added by this commit.
* update comment
* include help entry for -replace
* add to website docs as well
* Update internal/command/apply.go
Co-authored-by: Daniel Banck <dbanck@users.noreply.github.com>
* Update website/docs/cli/commands/apply.mdx
Co-authored-by: Daniel Banck <dbanck@users.noreply.github.com>
---------
Co-authored-by: Daniel Banck <dbanck@users.noreply.github.com>
* Fix defects where `done` is called before the command's `Run` method is invoked
We're attempting to reading output from a command that hasn't been executed yet!
* Another one
* configschema: Add identity attribute to import block
* Mark import target ID as legacy
* Add test with import identity
* Use ID or identity when importing via configuration
* Add plan import tests
* Review Feedback
* Make sure to copy identity for ResourceInstanceObjects
* Add helper for converting cty.Objects to string
* Replace getProvider calls
* Improve unknown object check
* Update URLs from www.terraform.io to developer.hashicorp.com
* More updates to URLs linking to documentation in documentation and user-facing warnings/errors
* More updates to URLs linking to documentation, in docs, code, test fixtures
* Replace www.terraform.io/community with link to Community Forum
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
---------
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Fix copy-pasta
* Update some comments clarifying backend-related interfaces and "enhanced" versus "operations"
* Fix more comments that refer to types and interfaces that have moved into the backendrun package
* jsonstate: Marshal identity values
* jsonstate: Test identity marshalling
* Add identity to prepareStateV4
* Check identity schema version when marshaling state
* Marshal identity for deposed resources
* Marshal identity version if `0`
* Check for missing resource identity schema
* Feat: Enhance elapsed time display in UI hook with minutes and seconds format
* changelog: improve elapsed time display in UI Hook (#36368)
* update test output to use zero-padded elapsed time format
* Add testing helpers for comparing diagnostics with different levels of stringency
* Refactor some existing tests to use the new helpers
* Replace use of diag comparison test helpers in terraform package
* Add header
* Add return statement back in ephemeral test
* Update internal/terraform/context_plan2_test.go
* Add `DiagnosticComparer` to standardize how diagnostics are compared for equality. This uses code originally in the s3 backend.
Co-authored-by: Graham Davison <gdavison@hashicorp.com>
* Refactor `test` related code to use new comparer
* Refactor `s3` related code to use new comparer
* Replace use of reflect and go-spew with new diagnostics comparison approach
* Fix whitespace
* Make `tfdiags.DiagnosticComparer` a var
* Fix DiagnosticComparer test
---------
Co-authored-by: Graham Davison <gdavison@hashicorp.com>
* Add details to `<failure>` element describing which assertion failed
* Remove unused diagnostic string
* Set `message` attribute of `<failure>` element to failed assertion's error message
* Make `<failure>` contain diagnostic's message, refactor how `message` attribute is set
* Ensure that system-err is only added when needed
* Update test fixtures
* Make diags usage clearer, ensure all test failure diags in "failure" element
* Refactor how "skipped" element value is set
* Fix failing test Test_TestJUnitXMLFile_Save
* Add ability for TestJUnitXMLFile to access data about whether the test runner was Stopped
* Add details to XML describing why a Run was skipped
* Fix wording
* Code consistency changes
* Move all JUnit-related code down to where it's used
Away from the Views section of the code where it was relevant before
* Move JUnit-related error and warning diags to above where cancellable contexts are created
* Fix wording of user feedback
* Fix test to match updated skipped message text
* Fix test
* feat: add state_alias for test run blocks
* fix: move `state_alias` to run block + rename to `state_key`
* docs: add state_key changelog entry
* docs: add state_key in run block documentation
* Revert "docs: add state_key in run block documentation"
This reverts commit ccccf62a76.
* Revert "docs: add state_key changelog entry"
This reverts commit 86e2ad8dc3.
* Promote JUnit reports for `terraform test` out of experimental status
* Make JUnit output explicitly for local execution only
* Refactor how local test runner is passed JUnit data
* Add change file
* Add test for incompatible flags
* Refactor JUnit XML output to use new concept of an Artifact
* Move JUnit-related code into new `artifact` package
* Refactor Artifact's Save method to return diagnostics, update comments
Previously TestJUnitXMLFile implemented the View interface, which cannot return errors. Now it's not a View any more we can simplify things.
* Make junitXMLTestReport output deterministic by iterating over a slice instead of a map, add test
* Provide sources to junitXMLTestReport, allowing complete error messages in the XML
We need to ensure that artifact.NewTestJUnitXMLFile is called once the config Loader is available as a non-nil pointer
* Whitespace
* Add some test coverage for JUnit XML output for `terraform test`
* Refactor how file is saved, add tests
* Move XML structs definitions outside of `junitXMLTestReport`
* Fix nil pointer bug
* Add missing file headers
* Refactor comparison of byte slices
* Rename package to `junit`, rename structs to match
* Add a test showing JUnit output when a test is skipped by the user
* Record metadata about the start timestamp for a Run/test case
* Add RFC3339 format timestamp attributes to `<testcase>` elements in JUnit XML output
* Ensure timestamps are saved as and rendered as UTC timestamps
The CLI attempts to prevent the user from inputting non-ephemeral
variables during apply which don't match the stored plan values. Since
the user can't avoid variables parsed from auto-loaded files, we have to
ignore those values.
Non-string input variables taken from the environment initially need to
be parsed and stored as string, since there is no type associated type
information. Make sure these are correctly handled when validated during
apply.
Plan allows undeclared config variables with only warnings, and that
behavior need to be carried forward to apply now that ephemeral
variables can be passed in at apply time.
This is a stopgap to give users some feedback when an ephemeral resource
contains unknowns and cannot be opened.
There is no json hook implementation so that the machine-readable spec
is not bound to the new output until further review. It doesn't really
fit with the current json ui model to have messages about what isn't
going to happen.
The cloud view is responsible for rendering messages related to cloud operations, presenting them to the user in either a human-readable format or as JSON output in the terminal.
Signed-off-by: Bruno Schaatsbergen <git@bschaatsbergen.com>
The cloud backend includes a retry hook that relies on a go-tfe implementation. Since these retry messages were not rendered through a view, the `-json` flag was not respected, leading to mixed (non-pure JSON) output in the terminal whenever retry messages were printed.
Before passing the init view to the cloud backend, we ensure the retryLog hook is included in the init view.
Signed-off-by: Bruno Schaatsbergen <git@bschaatsbergen.com>
This commit makes several modifications to the modules command. It
downcases the field names in the resulting JSON string, adds a format
version to the result. The result of this command will now only contain
entries which have been declared in configuration, as opposed to the
internal manifest which shows all installed modules for a working dir.
The modules command provides a holistic view of all installed modules
for a given root module. It also includes information on whether a
installed module is currently referenced by configuration. As of now,
this command only supports a machine-readable view format.
When key-value tags are enabled and used in the workspace, users may
define the tags attribute as a map of strings in the cloud block in order
to more precicely match workspaces using those tags.
* check root output values when determining plan applicability in refresh mode
In refresh-only mode, we do not anticipate proposing any actions; however, a plan is marked as “applyable” if there are changes in the state between runs. Currently, a plan is considered “applyable” only when there are differences in managed resources. This approach seems to overlook changes in root output values. As a result, a plan can be marked as non-applyable, even when there are changes in the root output value, due to the lack of detected changes since only managed resources were checked.
* set 'applyable' to true
* Remove handling of ephemeral root outputs
This is effectively reverting ~99% of https://github.com/hashicorp/terraform/pull/35676
The only changes not being reverted are some formatting and deprecation fixes which remain relevant.
The code being removed is basically dead code now in the context of root ephemeral outputs being rejected per https://github.com/hashicorp/terraform/pull/35791
* Remove unrelated changes
Some updates to staticcheck were catching more errors. Most of these
were format functions without a format string, but rather than adding
more exceptions I just fixed them all. This did also catch some
incorrectly wrapped errors.
Ephemeral root output values must be kept in the in-memory state representation, but not written to the state file. To achieve this, we store ephemeral root outputs separately from non-ephemeral root outputs, so Terraform can access them during a single plan or apply phase.
Ephemeral root outputs always have a value of null in the state file. This means that the "terraform output" command, that reads the state file, reports null values for these outputs. Consumers of 'terraform output -json' should use the presence of '"ephemeral": true' in such output to interpret the value correctly.
* show deprecation warning if -state is used with plan, apply, refresh
* show deprecation warning if -state is used with plan, apply, refresh
* updated -state flag check condition
* added better diagnostic details view
* resolved failed test
* updated the content of the -state flag warning
* lang: stabilise ephemeral values experiment
Stabilise the ephemeral values experiment and ephemeralasnull
experimental function.
* simplify handling of apply time input vars
As the final step in stabilising the ephemeral values experiment, we can
remove the separate code path for handling input variables supplied via
-var and -var-file during apply.
The intent here is conveyed in the tests: when applying a saved plan,
all ephemeral variables set in the plan (the "apply-time
variables"), must be set, and no others.
As per the TODO copied from the prototype, there is some more work to be
done here in making the handling of undeclared variables during apply as
sophisticated as that during plan, emitting helpful warnings (for
example) when input variables are supplied unnecessarily via environment
variables.
* experiments: officially conclude EV experiment
---------
Co-authored-by: Radek Simko <radek.simko@gmail.com>
We should not need to encode and decode change values within core, since
the encoded version is only technically needed for serialization. This
pattern stems from the conversion to current changes system, but back
then we did not have easy access to the correct schemas at the time to
encode and decode the entire set of changes.
Moving the core handling of changes to only use the decoded values will
drastically improve evaluation efficiency, removing a round trip
through encoded values for every resource reference.
On a default provider install failure we can always suggest running
`terraform providers` to help in cases where it's not apparent to the
user how to proceed. This would most commonly be encountered by
conflicting provider requirements, but if we find there are other common
situations we may want to generate a more precise error type for better
diagnostics.
This is another part of the existing ephemeral_values experiment, taking
a value of any type that might have ephemeral values in it and returning
a value of the same type which has any ephemeral value replaced with a
null value.
The primary purpose of this is to allow a module to conveniently return an
object that would normally contain nested ephemeral values -- such as an
instance of a managed resource type that has a write-only attribute --
through an output value that isn't declared as ephemeral. This would then
expose all of the non-ephemeral parts of the object but withhold the
ephemeral parts. In the case of write-only attributes, it exposes the
normal attributes while withholding the write-only ones.
The name of this function could potentially change before stabilization,
because it's quite long and clunky. I did originally consider
"nonephemeral" to match with the existing "nonsensitive", but that didn't
feel right because "nonsensitive" removes the sensitive mark while
preserving the underlying value while this function removes the mark and
the real value at the same time. (It would not be appropriate to have a
function that just removes the ephemeral mark while preserving the value,
because correct handling of ephemerality is important for correctness
while sensitivity is primarily a UI concern so we don't need to be quite
so picky about it.)
The providers mirror command was updated to inspect the lock file,
however that was not part of the original intent for the command, and
it's possible that the command needs to be run without a lock file.
Since we have been honoring the lock file for the past few releases,
let's keep that consistent and allow disabling the file with
`-lock-file=false`.
To support ephemeral values we need a more complicated set of rules about
what input variables can and must be set when applying a saved plan. The
command itself does not have enough information to implement those rules
itself, so we'll let them pass through and check this in the local
backend's apply phase instead.
The local backend's apply phase already had basic support for dealing with
apply-time variable values, but it'll now also be responsible for
rejecting attempts to set variables when the experiment isn't enabled,
to keep all of this logic in roughly the same place.
This is a checkpoint commit on the path to supporting ephemeral values as
a cross-cutting concern in the Terraform language. An ephemeral value is
one that lives only in RAM during a single phase and so cannot persist
from the plan phase to the apply phase, or between consecutive plan/apply
rounds.
Terraform tracks whether each value is ephemeral using the cty "marks"
concept, thus achieving the same dynamic analysis as we already employ for
the concept of "sensitive values" that prevents displaying a value in the
user interface.
This commit is just a starting point which gets some of the basics into
place:
- input variables and output values can both be statically declared as
being ephemeral. Only ephemeral inputs/outputs can have ephemeral values
assigned to them, and the recipient of the value sees it as ephemeral
even if the assigned value was not already ephemeral.
This creates a dynamic analysis cutoff point at module boundaries so
that it's possible to determine in isolation whether a single module is
using ephemeral values correctly, without having to test it in every
possible calling context.
- Managed and data resources cannot have ephemeral values assigned into
their configurations because Terraform and providers both expect the
resource attributes to persist between phases.
- Ephemeral values _can_ be used in provider and provisioner
configurations, because both of those effectively meet the definition
of the new "ephemeral" concept despite it not previously having a name.
- Ephemeral markings propagate through all of the built-in language
features for dynamic analysis purposes, largely relying on cty's efforts
to do that in similar vein as for sensitive marks. In particular,
it's possible to define a local value whose expression produces
an ephemeral result, and passing ephemeral values to functions should
propagate the ephemeral mark to the results when appropriate. (I've not
yet thoroughly reviewed all of the built-in functions for correct
marks handling though, so there may be some gaps to address in later
commits.)
The next step for this work will be to change the modules runtime to have
support for a workflow involving ephemeral _root_ input variables, where
their values must be re-supplied during the apply phase. That will then
achieve (in experimental capacity) the first goal of ephemeral values: to
be able to provide non-persistent settings such as time-limited API tokens
to use in provider configuration blocks.
The plan renderer was missing a check for entirely unknown blocks,
causing them to be omitted from the human readable output. An unknown
block can happen when using an unknown for_each value in a dynamic block
assignment.
* stop invalid warning during cleanup phase
* stop invalid warning during cleanup phase
* invalid warning during cleanup phase
* remove unwanted comment
* update GetVariables parameter for including warnings
* invalid warning during cleanup phase test case
* update invalid warnings in cleanup test case to throw a warning for the validation variable before cleanup phase
* remove unwanted warnings
* terraform test: Push evaluation of variables to as late as possible
* Update internal/moduletest/hcl/variable_cache.go
Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>
* address comments
---------
Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>
