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.

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

Annotate a Data Value with validation #604

Closed
Tracked by #561
pivotaljohn opened this issue Feb 7, 2022 · 4 comments
Closed
Tracked by #561

Annotate a Data Value with validation #604

pivotaljohn opened this issue Feb 7, 2022 · 4 comments
Assignees

Comments

@pivotaljohn
Copy link
Contributor

pivotaljohn commented Feb 7, 2022

Given a Data Values document (and only a Data Values document), annotated with a validation rule:

#! values.yml

@data/values
---
#@assert/validate ("a non-empty string", lambda v: assert.fail("length = {}", len(v)) if len(v) > 0 else None)
username: ""

Scenario: Invalid Data Value

Given the final Data Value's value does not satisfies the rule:
When ytt runs
Then reports a Data Values violation error message:

$ ytt -f values.yml --data-values-inspect
ytt: Error: One or more data values were invalid:
- "adminPort" requires a valid value: a non-empty string; length = 0 (validated by values.yml:6).

Scenario: Valid Data Value

Given the final Data Value's value satisfies the rule:
Then no error message is displayed.

$ ytt -f values.yml -v username=alice --data-values-inspect
username: alice

Note: validations are checked after all overlays have been applied.


Notes:

  • we show evaluating just one rule on one data value. We'll ultimately support evaluating multiple rules per Data Value, and evaluate validity of as many data values as possible.
  • one has to use the feature to opt-in. In a near-future story, we'll implement a feature flag.
  • while assertions work well with schema, a current design goal is to implement them orthogonally: this story establishes the core feature of validation; a subsequent story (Annotate Data Value Schema with validation #611) covers declaring a validation within schema.
  • we anticipate users seeing "violation messages" more often and in larger volume; hence the more compact error message format being highlighted. Feel free to play with the format and verbiage — what's given in the story is a "thoughtful suggestion" not the final word.
  • https://github.com/vmware-tanzu/carvel/blob/004-schema-validation/proposals/ytt/004-schema-validation/README.md#assertvalidate
@pivotaljohn pivotaljohn mentioned this issue Feb 7, 2022
19 tasks
@gcheadle-vmware
Copy link
Contributor

Should the #@assert/validate annotation work on data values contained in a data values file?

#@ load("@ytt:assert", "assert")
@data/values
---
#@assert/validate ("a non-empty string", lambda v: assert.fail("length = {}", len(v)) if len(v) > 0 else None)
username: "andrew"

@pivotaljohn
Copy link
Contributor Author

Should the #@assert/validate annotation work on data values contained in a data values file?

Insightful question. And I think you intuition is right: that an @assert/validate should mean the same thing everywhere (just like an @overlay/match does).

This points to a need to be able to declare the need for an @assert/validate (specifically in a document containing schema).

Folding this into the overall proposal.

🙌🏻

pivotaljohn pushed a commit to carvel-dev/carvel that referenced this issue Feb 16, 2022
Following discussions with
[gcheadle-vmware](carvel-dev/ytt#604 (comment))
and @cppforlife, it became clear that @assert/validate ought to always
be consumed in a step after overlays are applied for the current
pipeline.

When writing schema, the author intends not for the schema document
_itself_ to be validated, but to validate the _produced_ document (of
which the schema is a basis for).

Authors need a way to declare the intention for a validation to be
attached to the type composite: @schema/validation.
pivotaljohn pushed a commit to carvel-dev/carvel that referenced this issue Feb 16, 2022
Following discussions with
[gcheadle-vmware](carvel-dev/ytt#604 (comment))
and @cppforlife, it became clear that @assert/validate ought to always
be consumed in a step after overlays are applied for the current
pipeline.

When writing schema, the author intends not for the schema document
_itself_ to be validated, but to validate the _produced_ document (of
which the schema is a basis for).

Authors need a way to declare the intention for a validation to be
attached to the type composite: @schema/validation.
@pivotaljohn
Copy link
Contributor Author

Split this story into two:

@gcheadle-vmware
Copy link
Contributor

Closing since follow up PR was merged.

mamachanko pushed a commit to mamachanko/carvel that referenced this issue Oct 24, 2022
Following discussions with
[gcheadle-vmware](carvel-dev/ytt#604 (comment))
and @cppforlife, it became clear that @assert/validate ought to always
be consumed in a step after overlays are applied for the current
pipeline.

When writing schema, the author intends not for the schema document
_itself_ to be validated, but to validate the _produced_ document (of
which the schema is a basis for).

Authors need a way to declare the intention for a validation to be
attached to the type composite: @schema/validation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants