variable and output deprecation #38001
Conversation
This struct tracks and validates deprecations in the context of a graph walk. We need a struct to keep track of the module calls that opt-out of deprecation warnings.
DanielMSchmidt
force-pushed
the
add-deprecation-surpression-tracking
branch
from
5402a27 to
008e320
Compare
Variables can be deprecated through the `deprecated` attribute. If set the variable will emit a diagnostic if a values is passed to it. This entails both root level and module variables. Outputs can be deprecated through the `deprecated` attribute as well. If set wherever the value is used a diagnostic will be emitted. Root level outputs can not be deprecated. The only acceptable usage of a deprecated output is another deprecated output (forwarding the deprecation to the module user). If modules not under your control have deprecation warnings you can add a `suppress_deprecations_warnigns` attribute to the module call in question to silence any deeply nested warnings.
DanielMSchmidt
force-pushed
the
deprecations-in-variables-and-outputs
branch
from
82b8b89 to
4c5d964
Compare
| // cty.Value to a map[string]cty.Value for compatibility with other calls. | ||
| func evaluateForEachExpression(expr hcl.Expression, ctx EvalContext, allowUnknown bool) (forEach map[string]cty.Value, known bool, diags tfdiags.Diagnostics) { | ||
| return newForEachEvaluator(expr, ctx, allowUnknown).ResourceValue() | ||
| func evaluateForEachExpression(expr hcl.Expression, ctx EvalContext, module addrs.Module, allowUnknown bool) (forEach map[string]cty.Value, known bool, diags tfdiags.Diagnostics) { |
There was a problem hiding this comment.
I think the EvalContext has all the information? ctx.Path() returns the currently evaluated ModuleInstance
There was a problem hiding this comment.
Depending on when the evaluation is called ctx.Path() was returning nil sometimes, leading to strange behavior. Passing the module in seemed to give more predictable results, but I could try it again if we don't like the added API surface.
There was a problem hiding this comment.
null is a valid value for the root module instance, because RootModuleInstance is just the zero value of ModuleInstance. The Path() method will panic if it's not configured correctly.
If something is returning the wrong path, that is a problem somewhere, but I would more likely suspect it to be a test problem with the mock context.
| } | ||
|
|
||
| // We don't care about the returned value here, only the diagnostics | ||
| module := addrs.RootModule // TODO: FIXME |
There was a problem hiding this comment.
I should really add a linter for new TODOs and FIXMEs :D
DanielMSchmidt
force-pushed
the
add-deprecation-surpression-tracking
branch
2 times, most recently
from
8b295d5 to
2746850
Compare
2 participants
Variables can be deprecated through the
deprecatedattribute. If set the variable will emit a diagnostic if a values is passed to it. This entails both root level and module variables.Outputs can be deprecated through the
deprecatedattribute as well. If set wherever the value is used a diagnostic will be emitted. Root level outputs can not be deprecated. The only acceptable usage of a deprecated output is another deprecated output (forwarding the deprecation to the module user).If modules not under your control have deprecation warnings you can add a
suppress_deprecations_warnignsattribute to the module call in question to silence any deeply nested warnings.For the full end-to-end implementation see #37795, this PR splits up that work into more reviewable chunks.
Fixes #
Target Release
1.15.x
Rollback Plan
Changes to Security Controls
Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.
CHANGELOG entry