Skip to content

feat(validate): add ability to further constrain schema #2677

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

Merged
merged 1 commit into from
Jan 19, 2024

Conversation

GeorgeMac
Copy link
Contributor

This is in response to a discussion had with our friends at Paradigm.

The request was:

Hi team, given we have flipt validate is there perhaps a way to force some fields to be mandatory?
In our case description is required or we won't have people  outside of developers knowing what that flag actually does.

We leverage CUE under the hood to power flipt validate and this is driven by our flipt feature CUE schema:

close({
version: "1.0" | "1.1" | *"1.2"
namespace: string & =~"^[-_,A-Za-z0-9]+$" | *"default"
flags: [...{_version: version} & #Flag]
segments: [...#Segment]
})
#Flag: {
_version: string
key: string & =~"^[-_,A-Za-z0-9]+$"
name: string & =~"^.+$"
description?: string
enabled: bool | *false
variants: [...#Variant]
rules: [...#Rule]
if _version == "1.1" || _version == "1.2" {
type: "BOOLEAN_FLAG_TYPE" | *"VARIANT_FLAG_TYPE"
#FlagBoolean | *{}
}
}

This proposed change adds the ability to extend this schema with your own valid subset of this schema.

flipt validate -e extended.cue features.json

Taking the original request to be able to make e.g. description required, this could be achieved with the following extensions to the base schema (in extended.cue):

#Flag: {
	description: =~"^.+$"
}

This adds to the existing #Flag definition and says that description is required (drops the ?) and that is must be a non-empty string (matches the regexp =~"^.+$").
Taking the following JSON example in a file named features.json:

{
  "flags": [{"key": "foo", "name": "Foo"}]
}

Without the extended CUE definition, flipt validate will pass:

flipt validate features.jsonecho $?
0

However, by passing in the extended CUE definition via -e (short for --extra-schema) we can add the restrictions:

flipt validate -e extended.cue features.json
Validation failed!

- Message  : flags.0.description: incomplete value =~"^.+$"
  File     : features.json
  Line     : 2

@GeorgeMac GeorgeMac requested a review from a team as a code owner January 19, 2024 10:29
Copy link

codecov bot commented Jan 19, 2024

Codecov Report

Attention: 16 lines in your changes are missing coverage. Please review.

Comparison is base (de98001) 72.99% compared to head (6c14055) 72.87%.

Files Patch % Lines
internal/cue/validate.go 29.41% 11 Missing and 1 partial ⚠️
internal/storage/fs/snapshot.go 75.00% 4 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2677      +/-   ##
==========================================
- Coverage   72.99%   72.87%   -0.13%     
==========================================
  Files          85       85              
  Lines        8325     8346      +21     
==========================================
+ Hits         6077     6082       +5     
- Misses       1871     1886      +15     
- Partials      377      378       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@markphelps markphelps left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Would you mind cue'ing up (haha) a docs PR?

@GeorgeMac GeorgeMac merged commit c8532c1 into main Jan 19, 2024
@GeorgeMac GeorgeMac deleted the gm/flipt-validate-extra-schema branch January 19, 2024 14:13
@GeorgeMac
Copy link
Contributor Author

I see what you did there

@markphelps
Copy link
Collaborator

@GeorgeMac there seems to be a slight bug in nightly where it doesn't report the line number accurately

@markphelps markphelps removed the needs docs Requires documentation updates label Jan 23, 2024
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

Successfully merging this pull request may close these issues.

2 participants