Community support - where do want to be in a year?

Johnathan Mantey johnathanx.mantey at intel.com
Sat Feb 15 03:55:10 AEDT 2020


Brad,

The current test flow, when I tried yesterday, doesn't do well when the
current repo relies on some other chunk of the code base to succeed.

For example:
DBus changes an established item from bool to enum
Networkd uses the new enum type.

Git clone phosphor-networkd, run test.
Docker creates a new machine, populates the new machine, fetches the
code, from the upstream (which won't have the DBus), wait 20 or more
minutes, witness a failure.

It would be great to use my current devtooled state, and get the test
suite run with my current development state.
The phosphor-network test suite probably runs in under 1 minute.

I should be able to tweak code, run tests, see failure readily, tweak
code, rinse repeat.
I don't need the same level of verification that the QA team does.
Destroying the machine, and rebuilding it doesn't provide value.
If tests were quick to run there might be more incentive to creating
more tests.
As it stands, it is too onerous to bother.

On 2/14/20 8:33 AM, Brad Bishop wrote:
>
>> On Feb 14, 2020, at 10:24 AM, Johnathan Mantey <johnathanx.mantey at intel.com> wrote:
>>
>> Kurt,
>>
>> I would like to see a more developer friendly unit test framework.
>> I have had only a couple of occasions where I needed to run the test suite.
>> My most recent attempt was not successful because my test repo was out of sync with the remainder of the OBMC infrastructure.
>> I would like to see:
>>
>> 	• A way to test my changes within the framework of more than one repo.
>> 	• A less heavy handed,
> I assume the heavy-handed part is the need for docker?

-- 
Johnathan Mantey
Senior Software Engineer
*azad te**chnology partners*
Contributing to Technology Innovation since 1992
Phone: (503) 712-6764
Email: johnathanx.mantey at intel.com <mailto:johnathanx.mantey at intel.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200214/93d7f673/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200214/93d7f673/attachment-0001.sig>


More information about the openbmc mailing list