Re: [PATCH 2/8] oeqa/sdkext/devtool.py: remove workspace/sources before running test cases

[Robert Yang <liezhi.yang@windriver.com>]

On 12/13/2016 04:21 PM, Paul Eggleton wrote:
> On Tue, 13 Dec 2016 14:47:10 Robert Yang wrote:
>> On 12/13/2016 02:29 PM, Paul Eggleton wrote:
>>> On Tue, 13 Dec 2016 13:56:05 Robert Yang wrote:
>>>> On 12/13/2016 12:45 PM, Paul Eggleton wrote:
>>>>> It seems to me that's what's missing here is a proper teardown process
>>>>> like we have for oe-selftest, so that tests clean up after themselves
>>>>> whether they succeed or fail. I'm unsure as to whether that is part of
>>>>> the plan for the new QA refactoring though.
>>>>
>>>> There is already a 'devtool reset' which can do the cleanup, but it
>>>> can't remove sources as I said in the commit log.
>>>
>>> devtool reset not deleting the source tree is intentional - I don't want
>>
>> Add an option like "devtool reset --force" ? When I met the error, the first
>> I did was check "devtool reset", but there is no way to remove resources,
>> so I have to remove it here to allow multilib test cases runs.
>
> I've considered this and decided against it - it just seems to me that at
> least one person will use it every time until one day when they wipe out their
> source with their changes in it. I'd really rather not be enabling that.
> Besides, in everyday use repeated runs of devtool add / modify on the same
> recipe should be at a minimum, if that's not the case then we have other
> issues to look at.
>
> You say there's no way to remove these, but there is - just delete the files
> explicitly.
>
>> Or maybe fix "devtool add" to check the git repo correclty ? For example,
>> when there is already a repo, just update it rather than clone it again.
>
> Right, that has been suggested - and it's all fine if the source tree is
> unmodified and just a straight update to get from where it is currently to
> match the upstream. However, what if it's not fast-forward, or a different
> repo entirely? What if there are local modifications?
>
>> The multilib + testsdkext would fail without this fix.
>
> Yes, that's why I ultimately said we haven't much choice but to apply this
> patch. We must acknowledge however that the problem exists because the tests

Got it, thanks.

// Robert

> aren't cleaning up after themselves, which should be their responsibility.
>
> Cheers,
> Paul
>