-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
feat: validate message object examples with spectral schemas #782
feat: validate message object examples with spectral schemas #782
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of comments / questions for others
@@ -238,6 +239,7 @@ export const v2SchemasRuleset = (parser: Parser) => { | |||
}, | |||
}, | |||
}, | |||
'asyncapi2-message-examples-custom-format': asyncApi2MessageExamplesParserRule(parser), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the rule in but might not want to do this yet. If not, need a pointer on how to get the tests to run without being in the ruleset
There is code duplication w.r.t to the old rule. I can deal with this after review / thoughts on what's there |
has duplication which I can sort out with other comments. and is out of date with base now I think, but any comments on the code are appreciated @jonaslagoni |
I dont think it changed, I just need to find some time to review it ASAP 😅 |
This will probably need some slight changes / merge conflict resolutions from #786 |
@chrispatmore fixed the conflicts, gonna review this once I get back from the gym 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrispatmore would it make sense to add the rule ONLY for when schemaFormat has been defined? i.e. that is the difference between the two spectral rules and they can both live together without having to change that down the road?
Cause that would remove all duplicated code parts and tests and simplify the approach by a mile
Let me take a look. Forcing me to play around with json path expressions again 😉 |
validate message object examples against the schemas in the object by parsing the schemas using spectral before validation this proves that the examples are valid Signed-off-by: Chris Patmore <[email protected]>
Signed-off-by: Chris Patmore <[email protected]>
switch the new rule to only run of the schemaFormat is set in the message. Also adjust the tests to better align with this separation. Signed-off-by: Chris Patmore <[email protected]>
b5a47e4
to
26eda0c
Compare
@jonaslagoni This block still duplicated across the two rules:
Not really sure how best to de-depe. Could export from the first one so new once can use, but they're so minor I'm not sure it's worth it |
That code smell is false positive, if I remove the |
Signed-off-by: Chris Patmore <[email protected]>
How did removing code increase duplication... Edit: ah now it's finding the duplicated scenarios in the tests. I think these duplicate usages are valid, because they highlight the difference in behaviour between the two rules |
@jonaslagoni thoughts on duplication in the tests? |
headers: { | ||
type: 'record', | ||
name: 'TestHeader', | ||
fields: [ | ||
{name: 'someKey', type: 'string'}, | ||
{name: 'someOtherKey', type: 'string'} | ||
] | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was this change for? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I added this when the same tests were being used for both rules, to ensure no change in behaviour, less relevant now, can remove
@@ -378,19 +390,32 @@ testRule('asyncapi2-message-examples', [ | |||
{name: 'speed', type: 'string'} | |||
] | |||
}, | |||
headers: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty sure headers cannot be avro 🤔 At least not in v2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No I added the headers to the original tests (schemaFormat not set case) so that It added confidence that header behaviour was maintained across both versions of the rule (before we decided to split the rules)
I can revert this.
Though the new info that headers cannot be v2 means I can simplify the new v2 rule!
Sorry @chrispatmore I am context-switching like crazy at the moment, might be forgetting stuff... Do correct me if I say something completely off the chart 😄 |
remove logic expecting headers to be avro remove redundant test pieces Signed-off-by: Chris Patmore <[email protected]>
No worries @jonaslagoni not in any particular rush. Have adapted to your comments. The headers cant be avro was interesting, because my rule validating the headers examples against an avro header schema was perfectly happy with it! Have removed it regardless as, as you say it's not allowed in the spec atm I expect we will still have quite high duplication in the test spect |
Hey @jonaslagoni , I am back from a little break, what are we thinking here? |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
/rtm |
Thanks for the patience @chrispatmore, sorry it took so long 🙏 |
🎉 This PR is included in version 2.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Thanks @jonaslagoni no worries ! |
validate message object examples against the schemas in the
object by parsing the schemas using spectral before validating
this proves that the examples are valid.
Related issue(s)
Contributes to: #781
Signed-off-by: Chris Patmore [email protected]