#2: Getting just the library generation in place to library-based ser…

[brynrhodes]

…vices have the content

[suyashkumar]

Hi Bryn--just a question: Do we need to actually check in these derived artifacts into the cql-tests-runner repo, or can these be generated on the fly by the runner as needed from the "canonical" test definition XML at runtime only?

I'm wondering checking this opens up the potential for accidental skew if one of these files is modified but the canonicial test definition isn't, or confusion for users on what's the canonical definition. That said if we have some kind of presubmit checking that can say if the cql-tests submodule commit is updated, then all of these files must be re-generated (e.g. run the tests to refresh this definition), that would help prevent this skew.

Either way, the real question I have is--what's the main benefit of including these? Perhaps the main benefit is for users to be able to inspect/debug the intermediate artifacts?

(note I don't feel strongly, just curious)

[brynrhodes]

Hi @suyashkumar , 100% agree, these shouldn't be committed, I only committed them because some of the engines wanted the XML/JSON serialization of the libraries, so this was a stopgap to support that

[richfirely]

Suggested change

	var body = 'library ' + testsName + os.EOL + os.EOL + body;
	var body = 'library ' + testsName + ' version \'1.0.000\'' + os.EOL + os.EOL + body;