Retire redundant Perl/Python validation

[HebaruSan]

Currently every NetKAN pull request's validation output says:

Running basic sanity tests on metadata.
If these fail, then fix whatever is causing them first.
t/inflate.t ... skipped: Not a travis pull request
t/metadata.t .. ok
All tests successful.
Files=2, Tests=13863,  3 wallclock secs ( 1.10 usr  0.11 sys +  1.98 cusr  0.20 csys =  3.39 CPU)
Result: PASS

... and later:

Validating built/BobsPanicBox-1-0.0.1.19.ckan.. Success!

These messages are the result of running prove and ckan-validate.py, which perform assorted checks on the metadata relevant to the pull request.

As of KSP-CKAN/CKAN#2788, these tests are done by netkan.exe itself. If the generated metadata doesn't obey the schema or has any other validation problem, an error will be printed and the file won't be generated. This means that this Perl/Python validation is now redundant.

This pull request removes these validation checks.

Checks not removed:

• The doesn't match any valid game version check is retained even though it is also part of netkan.exe now because it functions as a sanity check to make sure that something hasn't gone wrong with that part of the script
• The jsonlint check performs strict syntactic validation of the .netkan file; unlike the schema checks, it looks for things like extra or missing commas, which is useful because .netkan files are edited by humans and therefore subject to such errors
• The CKAN-meta build.sh script still uses ckan-validate.py because that repo does not use netkan.exe and so cannot rely on it for validation (yet, maybe in future)

[techman83]

My only comment here is that metadata.t runs across the whole repo. It will catch things accidentally merged in or in the case of a spec change to fix something showing up an issue with old metadata.

Though I'm not opposed to cleaning up the test scripts. They contain a lot of logic in them, done in bash.

Also, in theory NetKAN can consume a CKAN and output a validated CKAN. Maybe md5 before/after and we can catch when a CKAN is handcrafted (which we never want to do).

[HebaruSan]

My only comment here is that metadata.t runs across the whole repo. It will catch things accidentally merged in or in the case of a spec change to fix something showing up an issue with old metadata.

No question there's value in that, but I see that as a use case for the bot, not pull request validation scripts. For a pull request, all I care about is problems that are relevant to the changes made by the pull request. It's a pain to have to drop everything to clean up Sarbian's extra commas and then rebase a PR just to get the validation output specific to that PR's actual changes.

Also, in theory NetKAN can consume a CKAN and output a validated CKAN.

Yup, I might do that next. netkan.exe --validate-ckan would almost be a C# one-liner at this point.
Not sure what you mean about MD5s and hand crafted .ckans. Oh, like netkan would print out the metadata, but with cleaned up formatting? I was thinking we would just run the validators and print any errors. Interesting idea.

[techman83]

No question there's value in that, but I see that as a use case for the bot, not pull request validation scripts. For a pull request, all I care about is problems that are relevant to the changes made by the pull request. It's a pain to have to drop everything to clean up Sarbian's extra commas and then rebase a PR just to get the validation output specific to that PR's actual changes.

That's a pretty valid point. There are things we can do to check the health of our metadata and we'll have the means to do it. A lot of this was written when we didn't. Thanks for sticking with me!

Yup, I might do that next. netkan.exe --validate-ckan would almost be a C# one-liner at this point.
Not sure what you mean about MD5s and hand crafted .ckans. Oh, like netkan would print out the metadata, but with cleaned up formatting? I was thinking we would just run the validators and print any errors. Interesting idea.

Yep. We should output and compare the files. If they don't match, fail the build.

For now, I shall merge this! Awesome work 🙂