Re: Generating manifests for the test runner

So, what in-test-file data does it use?  I was already asking
previously about what metadata needed to be in tests, and the
consensus seemed to be pretty much "none".

How does the manifest generator distinguish between support files,
READMEs, and real test cases, for example?

On Wed, Jul 23, 2014 at 1:52 AM, James Graham <james@hoppipolla.co.uk> wrote:
> On 23/07/14 01:08, Michael[tm] Smith wrote:
>> Hi Brad,
>>
>> ./tools/scripts/manifest.py --experimental-include-local-changes
>>
>> You need to feed the script that
>> "--experimental-include-local-changes" switch.
>
> Yes, so fundamentally the idea of the generated manifest file is that
> it entirely uses in-test-file data to identify tests and their
> properties. Unfortunately this makes it rather slow to regenerate the
> manifest for the whole repository since it involves parsing all the
> HTML files, among other things. As such we need to support incremental
> updates to the manifest. But the combination of incremental updates
> between revisions and adding data from uncommitted local files is
> slightly non-trivial to support; one doesn't want to end up with items
> in the manifest corresponding to files that were never committed and
> no longer exist, for example. I am not confident that the current
> approach to this in the code is good enough.
>
> It's quite possible that improvements can be made. For example, with
> files that have been modified it should first generate the correct
> data for HEAD and then separately store the data for the working tree
> copy. On update all data for non-comitted modifications would be
> discarded. I will be able to look at this relatively soon, I would think.
>
> It also should be possible to ensure that all consumers of the
> manifest generate it as needed, so that there is never any need to
> manually initiate the generation.
>

Received on Wednesday, 23 July 2014 18:09:22 UTC