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

travis: Choose schema based on USE_OLD_SCHEMA file (strict) #1074

Merged
merged 3 commits into from
Feb 10, 2018
Merged

travis: Choose schema based on USE_OLD_SCHEMA file (strict) #1074

merged 3 commits into from
Feb 10, 2018

Conversation

petertseng
Copy link
Member

@petertseng petertseng commented Jan 5, 2018

The strict version of #1072: Enforces that we will not forget to remove the USE_OLD_SCHEMA file.

If it is present, use the old schema, else use the new schema.

This plan is proposed in:
#998

Its merits are that it allows us to:

  • Track progress by simply counting number of USE_OLD_SCHEMA file.
  • Verify, as each PR is made, that each JSON file intending to use new
    schema does in fact validate.
    • Otherwise we have to manually run a schema check at periodic
      intervals.
  • Keep compatibility with old schema, to support moving over one file at
    a time instead of all at once.

Note that old-schema.json is the same canonical-schema.json as is
currently on master.

The intention is that when all exercises use the new schema, the
commit "travis: Choose schema based on USE_OLD_SCHEMA file" can/should
be reverted
and then all exercises will in fact use the new schema,
which will replace the old completely.

@petertseng
Copy link
Member Author

Warning. Confusing CI output.

exercises/alphametics/canonical-data.json valid
exercises/alphametics/canonical-data.json invalid
[ { keyword: 'oneOf',
    dataPath: '.cases[0]',
    schemaPath: '#/oneOf',
    params: {},
    message: 'should match exactly one schema in oneOf' } ]

This is saying:

  • alphametics is valid under the old schema.
  • alphametics is invalid under the new schema.

Since alphametics intends to use the old schema, it must be the case that it is valid under the old schema and invalid under the new schema, so this is correct, but confusing.

I'd suggest that I suppress the output from the invalid-under-new check!

@petertseng
Copy link
Member Author

#1075 demonstrates all three possible modes of failure.

@petertseng
Copy link
Member Author

Rebased

, "properties" :
{ "description": { "$ref": "#/definitions/description" }
, "comments" : { "$ref": "#/definitions/comments" }
, "property" : { "$ref": "#/definitions/property" }
, "input" : { "$ref": "#/definitions/input" }
Copy link
Member Author

Choose a reason for hiding this comment

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

how did I cause this to get misaligned?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because I was lazy in #998.

@petertseng
Copy link
Member Author

Excuse me for a moment. Temporarily need to commandeer this PR to test #1129 and #1130. I refuse to merge or review input object PRs without having them be tested.

@ErikSchierboom
Copy link
Member

@petertseng I was wondering if you could re-run the script to see how many (and which) exercises don't conform to the new schema?

@petertseng
Copy link
Member Author

The way to track progress is to merge this PR, not to keep rebasing it. However, you are in luck, because to merge this it needs to be rebased anyway.

@rpottsoh rpottsoh requested a review from Stargator February 9, 2018 18:57
@rpottsoh
Copy link
Member

rpottsoh commented Feb 9, 2018

Ugh, request for review request was accidental on my part...

@rpottsoh rpottsoh removed the request for review from Stargator February 9, 2018 19:01
@ErikSchierboom
Copy link
Member

@petertseng This PR looks good and the CI is green. Is there anything we should be waiting for before we merge this?

Derived from the list of invalid exercises listed in:
#998 (comment)
This schema was proposed and accepted in
#996
@petertseng
Copy link
Member Author

petertseng commented Feb 10, 2018

Is there anything we should be waiting for before we merge this?

No, there is nothing to wait for.

As a rule, if I have not marked a PR as "DO NOT MERGE" I intend for it to be merged. But nobody Approved (in the GitHub sense of the word), so I did not merge it.

Only potential thing to watch out for:

If some exercise has moved to the new schema since the last time this PR was rebased[1], then the CI will appear to pass, but will actually fail when this PR is merged.

[1]: Not quite true, since Travis CI checks the result of merging, but I'd need to figure out whether Restart Build button recalculates the commit to merge with.

.travis.yml Outdated
if ajv -s canonical-schema.json -d $json 2>/dev/null; then
forgotten="$forgotten $ex"
fi
schema="old-schema.json"
Copy link
Member Author

Choose a reason for hiding this comment

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

sorry, what? is this necessary?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah no, it was not necessary. This line has been removed.

If it is present, use the old schema, else use the new schema.

This plan is proposed in:
#998

Its merits are that it allows us to:

* Track progress by simply counting number of USE_OLD_SCHEMA file.
* Verify, as each PR is made, that each JSON file intending to use new
  schema does in fact validate.
  * Otherwise we have to manually run a schema check at periodic
    intervals.
* Keep compatibility with old schema, to support moving over one file at
  a time instead of all at once.

Note that old-schema.json is the same canonical-schema.json as is
currently on master.

The intention is that when all exercises use the new schema, **this
commit can/should be reverted** and then all exercises will in fact use
the new schema, which will replace the old completely.
Copy link
Member Author

@petertseng petertseng left a comment

Choose a reason for hiding this comment

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

OK, With apologies, I made some changes since the last approval, but I have confidence in them, and if I'm wrong, the responsibility on that lies with me alone.

git diff -u 3051deb36d2293baff9f3e5a47fa9e391f7ac388 HEAD

diff --git a/.travis.yml b/.travis.yml
index 7b98a41..b129a48 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -15,7 +15,6 @@ script:
       dir=$(dirname $json)
       ex=$(basename $dir)
 
-      schema="canonical-schema.json"
       if [ -f "$dir/USE_OLD_SCHEMA" ]; then
         if ! ajv -s old-schema.json -d $json; then
           invalid_old="$invalid_old $ex"
@@ -25,13 +24,11 @@ script:
         if ajv -s canonical-schema.json -d $json 2>/dev/null; then
           forgotten="$forgotten $ex"
         fi
-        schema="old-schema.json"
       else
         if ! ajv -s canonical-schema.json -d $json; then
           invalid_new="$invalid_new $ex"
         fi
       fi
-
     done
 
     stat=0

I am pretty sure those schema lines were in there because of #1072, and were not being used in this PR.

forgotten="$forgotten $ex"
fi
else
if ! ajv -s canonical-schema.json -d $json; then
Copy link
Member Author

Choose a reason for hiding this comment

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

this could have been an elsif but I didn't think it would make the code sufficiently clear.

@petertseng petertseng merged commit c7aa0ff into exercism:master Feb 10, 2018
@petertseng petertseng deleted the ci-new-schema-strict branch February 10, 2018 12:09
petertseng added a commit that referenced this pull request Feb 16, 2018
This reverts commit a866c43.

Observe that there are no more USE_OLD_SCHEMA files in this repository.
This indicates that henceforth all canonical-data.json files should use
the schema proposed in
#996 and
defined in #1074.
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.

3 participants