[pull] master from hashicorp:master #116
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Show resource name in taint -allow-missing warning
Add name to untaint missing warning
Rather than using a prior value of null to indicate create, which is imprecise because null is a valid output value, only plan values that didn't exist in the prior state as Create changes.
…m-version-check-again cli: Fix double check of remote workspace version
Create and Delete actions for output plans
I frequently see people attempting to ask questions about Terraform's error and warning messages but either only copying part of the message or accidentally copying a surrounding paragraph that isn't part of the message. While I'm sure some of these are just "careless" mistakes, I've also noticed that this has sometimes overlapped with someone asking a question whose answer is written directly in the part of the message they didn't include when copying, and so I have a theory that our current output doesn't create a good enough visual hierarchy for sighted users to understand where the diagnostic messages start and end when we show them in close proximity to other content, or to other diagnostic messages. As a result, some folks fail to notice the relevant message that might've answered their question. I tried a few different experiments for different approaches here, such as adding more horizontal rules to the output and coloring the detail text differently, but the approach that felt like the nicest compromise to me was what's implemented here, which is to add a vertical line along the left edge of each diagnostic message, colored to match with the typical color we use for each diagnostic severity. This means that the diagnostics end up slightly indented from what's around them, and the vertical line seems to help subtly signal how we intended the content to be grouped together.
CI: Add broken link checking job for website content
Change the word "date" to "data"
Previously the state migration process was using the fallback strict error check when migrating to or from a Terraform Cloud workspace. This resulted in an error when running init if the local and remote Terraform versions did not exactly match. This was excessively strict. When migrating from a remote Terraform Cloud workspace to local state, there is no need for a version check at all, as we cannot break the Terraform Cloud workspace. When migrating to Terraform Cloud, we should use the more forgiving check, rather than the strict equality. This commit fixes both of these cases accordingly, and allows migrating state to and from Terraform Cloud remote workspaces without errors.
InitProvisioner only stored the provisioner in the cache and provided a way to return an error. We can push this back further into the cli init process, but for now we can move the error into the Provisioner call and drop InitProvisioner. This also changes CloseProvisioner to CloseProvisioners, in preparation for the removal of the graph nodes.
Provisioners are always run via a single instance, and their configuration and references are taken care of via their parent resource, so there is no need to maintain the provisioner graph nodes. The only action that will still need to be completed is calling the Close method for external plugins. This was not consistently done with the current handling of provisioners anyway, and we can now add that to a single point with the new CloseProvisioners context method.
This was not done consistently in all cases when the individual provisioner graph nodes were used. Since we removed the graph nodes, the only thing left is to close these at the end of the walk.
Provisioner lifecycle
…ion-check-state-migration cli: Fix state migration remote version check
Move remaining helper/ packages to internal/
The existing context test files are becoming quite unwieldy. Start new ones both to make editing easier, and to help discourage the copy+pasting of older test patterns we no longer need.
The tainted state was checked against `cty.NilVal`, however it was always being set to a null value. The refreshed state value was being shadowed, and not used in the following plan.
Error planning tainted resource when it no longer exists
When planning a data source change, the object compatibility verification step should be performed with unmarked values. This value is transient and preserving marks is not necessary, and the object change code is not fully marks-aware.
This is just a prototype to gather some feedback in our ongoing research on integration testing of Terraform modules. The hope is that by having a command integrated into Terraform itself it'll be easier for interested module authors to give it a try, and also easier for us to iterate quickly based on feedback without having to coordinate across multiple codebases. Everything about this is subject to change even in future patch releases. Since it's a CLI command rather than a configuration language feature it's not using the language experiments mechanism, but generates a warning similar to the one language experiments generate in order to be clear that backward compatibility is not guaranteed.
Since this is still at an early phase and likely to change significantly in future iterations, rather than attempting to guess on a suitable final location for documenting the testing feature I've instead taken the unusual approach of adding a new page that is explicitly about the experiment. My expectation is that once we conclude the experiment we'll replace this new page with a stub that just explains that there was once an experiment and then links to whatever final feature unfolded from the research. The URL for this page is hard-coded into the warning message in the "terraform test" command, so as we continue to evolve this feature in future releases we'll need to update the callout note on the page about which Terraform CLI version it's currently talking about, so users of older versions can clearly see when they'd need to upgrade in order to participate in a later incarnation of the experiment.
cli: Migrate refresh to command views
The auto-approve argument was part of the arguments.Operation type, which resulted in adding a silent -auto-approve flag to plan and refresh. This was unintended, and is fixed in this commit by moving the flag to the arguments.Apply type and updating the downstream callers.
cli: Migrate plan to command views
Instead of returning an error with no context about unexpected attributes or incorrect types, notify users that the schema stored in the state does not match the current provider. User can only encounter this error if the providers have updated their schemas since the state was stored. This would appears when running `terraform show -json` to display the current state, or `terraform show -json planfile` if that plan was created with `-refresh=false`. In either case, the state must be refreshed in order to properly json encoded.
Provider transformer cleanup
Although we don't typically do configuration-level string wrangling directly in Terraform, we delegate to several other upstream libraries that do. These upgrades all switch to newer versions that support the latest definitions from Unicode 13, primarily affecting operations such as converting strings to upper/lowercase or splitting strings into component characters (substr, reverse, etc). The tests for the upstream libraries didn't show any regressions from these updates, so the Unicode 13 changes seem to be backward-compatible additions rather than significant breaking changes. (Our go.mod file had also become non-canonical in some ways, and the Go toolchain fixed that as part of this work, causing a few extra style-only diffs here that shouldn't cause any change in behavior.)
jsonstate: indicate schema version mismatch during encoding
Add State Learn tutorial to State docs
Document `inline` & `on_failure` behaviour
cli: Add reference to global options to help text
* Update Godoc links from godoc.org to pkg.go.dev * Update reference to renamed GraphNodeResource interface Ref #24389 * Update dead links; minor formatting adjustments * Add FIXME item following deprecation of EvalNode
…esourceConfig (#27874) * providers.Interface: rename ValidateDataSourceConfig to ValidateDataResourceConfig This PR came about after renaming ValidateResourceTypeConfig to ValidateResourceConfig: I now understand that we'd called it the former instead of the latter to indicate that the function wasn't necessarily operating on a resource that actually exists. A possibly-more-accurate renaming of both functions might then be ValidateManagedResourceConfig and ValidateDataResourceConfig. The next commit will update the protocol (v6 only) as well; these are in separate commits for reviewers and will get squashed together before merging. * extend renaming to protov6
Catch attributes which are planed but not computed separately to provide a clearer error to provider developers. The error conditions were previously caught, however it was unclear from the error text as to _why_ the change was an error. The statements about value inequality would be incorrect when planning no changes for a value which should not have been set in the first place.
#27904) this fixes a bad merge on my part
These flags are not used and have been deprecated since 0.12.11.
As usual, we'll continue to iterate on this based on feedback and questions during the beta period, but this is a first draft intended to help those who are trying out the first beta.
…m-validate cli: Remove -var/-var-file flags from validate
objchange: catch invalidly planned attributes earlier
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]. Want to support this open source service? Please star it : )