Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

core: Check rule error message expressions #30613

Merged
merged 4 commits into from Mar 7, 2022
Merged

core: Check rule error message expressions #30613

merged 4 commits into from Mar 7, 2022

Commits on Mar 4, 2022

  1. core: Check rule error message expressions 

    Error messages for preconditions, postconditions, and custom variable
validations have until now been string literals. This commit changes
this to treat the field as an HCL expression, which must evaluate to a
string. Most commonly this will either be a string literal or a template
expression.

When the check rule condition is evaluated, we also evaluate the error
message. This means that the error message should always evaluate to a
string value, even if the condition passes. If it does not, this will
result in an error diagnostic.

If the condition fails, and the error message also fails to evaluate, we
fall back to a default error message. This means that the check rule
failure will still be reported, alongside diagnostics explaining why the
custom error message failed to render.

As part of this change, we also necessarily remove the heuristic about
the error message format. This guidance can be readded in future as part
of a configuration hint system.
    @alisdair
    alisdair committed Mar 4, 2022
    Copy the full SHA
    b06fe04 View commit details
    Browse the repository at this point in the history

  2. core: Evaluate pre/postconditions during validate 

    During the validation walk, we attempt to proactively evaluate check
rule condition and error message expressions. This will help catch some
errors as early as possible.

At present, resource values in the validation walk are of dynamic type.
This means that any references to resources will cause validation to be
delayed, rather than presenting useful errors. Validation may still
catch other errors, and any future changes which cause better type
propagation will result in better validation too.
    @alisdair
    alisdair committed Mar 4, 2022
    Copy the full SHA
    b59bffa View commit details
    Browse the repository at this point in the history

  3. core: Add fallback for JSON syntax error messages 

    Custom variable validations specified using JSON syntax would always
parse error messages as string literals, even if they included template
expressions. We need to be as backwards compatible with this behaviour
as possible, which results in this complex fallback logic. More detail
about this in the extensive code comments.
    @alisdair
    alisdair committed Mar 4, 2022
    Copy the full SHA
    45d0c04 View commit details
    Browse the repository at this point in the history

  4. website: Update docs for check rule error messages

    @alisdair
    alisdair committed Mar 4, 2022
    Copy the full SHA
    f21d0e8 View commit details
    Browse the repository at this point in the history