-
Notifications
You must be signed in to change notification settings - Fork 77
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
Add initial support for Build.xml
submission file validation
#2277
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.
This seems reasonable to me, but I'd like @zackgalbreath to take a look before this gets merged to make sure all of the optional vs required fields are specified as expected.
Please do! It'd be very helpful if you looked for any missing fields, any assumptions made on expected number of occurrences of elements, and on their ordering. E.g., if the schema as written currently is assuming elements must be ordered in a certain way but the parsing code would actually accept it in any order, or the opposite, if the schema defines a sequence of unordered elements but our parsers expect to read them in a particular order. |
I ran this new validation step on all the Build.xml files received by open.cdash.org over the past couple days. The only problem I ran into was one site that apparently had a high enough CPU clock frequency that CTest represented that value using scientific notation 😮 . This is fixed by the commit I pushed onto this topic branch. As noted in the TODO comment in this new code, we will eventually need to pursue a streaming approach, particularly for |
Thanks @zackgalbreath! I'll make the changes to the validator in a separate PR. |
As part of our efforts to improve the CDash submission process, we working to introduce XML schematics to help with submission validation. The first of these PRs merged is #2277. The changes in this PR refactor some common element types that appear in many of the different XML types, and pull them out to a common file so they can be reused and instead of redefined by the other schema files. For an example where these elements type are used, see #2287.
This PR follows up on #2277 and introduces an initial schema for "Configure" XML file types accepted by the CDash submission process. The schema has been tested against all configure XML data files in the CDash repo. The changes also pull out some common element types into a `common.xsd` file to be reused by the other schema files.
This PR expands on the initial implementation of the submission XML validator introduced in #2277. The validator now supports parsing bigger XML files, can process multiple files per invocation, and provides better error handling. The logic for determining the submission XML file type has been pulled out to be used by both the submission parsers and the XML validation code. To use the validator from a CDash container, run: ``` php <cdash_base>/artisan submission:validate <xml_file>... ``` where `<cdash_base>` is the path to the application root directory (e.g., `/cdash`), and `<xml_file>...` are one or more file paths to to be validated.
The current error handling and logging for XML files submission parsing is not extensive enough, and it is not easily accessible to users making the submissions. This PR is the first in a series of changes meant to improve this aspect of the user experience.
The changes define an initial schema for valid "Build" XML files, and a tool to validate such files against it. The schema has been tested against all build XML data files in the CDash repo, as well as on production data (generated by CTest).
Future PRs are to expand on this by improving the rigor of the schema, defining schemas for all other upload types CDash accepts (update, configure, test, etc.), and incorporating the validation into our submission handling process.