-
-
Notifications
You must be signed in to change notification settings - Fork 554
DO NOT MERGE: trial new schema w/ input #998
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
Conversation
what we wanted to see |
fun fact: the one other exercise that is valid under the new schema, with no additional changes? ETL. |
schema-with-input.json
Outdated
, "property" : { "$ref": "#/definitions/property" } | ||
, "input" : { "$ref": "#/definitions/input" } | ||
, "expected" : { "$ref": "#/definitions/expected" } | ||
} |
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.
Should this disallow additional properties?
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 currently can't think of a need for other properties. So, great question and/or idea, let's do it.
To make this transition, it is:
I wonder if I should follow this plan: For each exercise: Its canonical-data.json file will be verified using the new schema, unless the directory contains a file named |
Do we need the extra file? |
This would fail miserably when someone misspells the `"input"` key.
|
I currently count five exercises compliant. |
currently exercises/acronym/canonical-data.json valid |
@petertseng Could you re-run the tool to see which exercises are now compliant? Is it also possible to see which exercise are not compliant? |
OK, rebased on master. Since I won't be around to report when it finishes, I'll have to leave it to you to read the output when it finishes.
Yes. |
Thanks @petertseng! The current status is as follows. Valid:
Invalid:
|
If we do this:
Since I predict I as a reviewer may make a mistake in reading the CI output carefully, I preferred to make the intention explicit instead of implicit. Since to me it makes a clearer history if we avoid having commits that look like "convert to new schema" (PR gets merged) "oops, actually convert to new schema correctly this time", I am biased toward making the review as error-free as possible, despite that we burden implementors with having to remember to However, since to date I have neither been an implementor nor a reviewer of PRs converting to the new schema, I think I had better defer my decision to those who have been in such positions. |
What should we do with test cases where there is no input? An example of this is the |
Among the choices I thought of were:
I think I would prefer
|
👍 |
Agreed! |
This schema was proposed and accepted in #996
No description provided.