Thanks for pointing out the yaml control file, that could be useful.  But
before we make any modifications to the OpenStack charms, I think it would
be helpful to have an agreed-upon convention for the following in terms of
Makefile target names:

   - nose / unit tests
      - make test
      - make unit_test
      - Both are in use.
      - 2 cents:  I would reserve both of these for unit tests, never for
      amulet tests.
   - lint checks
      - make lint
      - Already unified on this afaict.
   - amulet tests
   - make test
      - make functional_test
      - Both are in use.
      - 2 cents:  I think functional_test leaves no question as to usage.
   - charm-helpers sync
   - make sync
      - Already unified on this afaict.

If there is not a documented convention, can we have the necessary
discussions here to create one?

Thanks again,

Ryan




On Wed, Jan 21, 2015 at 11:40 AM, Benjamin Saller <
benjamin.sal...@canonical.com> wrote:

> While convention is great there is an additional path, you can if your
> project differs from the de facto standards, include an explicit list of
> targets in your tests/tests.yaml file
>
> makefile:
>     - lint
>     - unit_test
>     - something_else
>
> That file allows customization of much of bundletesters policy.
>
> -Ben
>
> On Wed, Jan 21, 2015 at 9:05 AM, Ryan Beisner <ryan.beis...@canonical.com>
> wrote:
>
>> Greetings,
>>
>> I'd like to invite discussion on Makefile target names.  I've seen a few
>> different takes on Makefile target naming conventions across charms.  For
>> example, in the OpenStack charms, `make test` runs amulet and `make
>> unit_test` performs nose tests.  In many/most other charms, `make test`
>> infers unit/nose testing, and amulet target names can vary.
>>
>> As I understand bundletester:  it expects `make test` to be unit tests.
>> Amulet targets in the Makefile aren't processed if they exist.  Instead,
>> the executables in the test dir are fired off.  And, I think that should
>> all be quite fine as long as the charm's amulet make target isn't doing
>> anything important.
>>
>> The net effect for OpenStack charms at the moment is that when they hit
>> Juju QA, amulet fires off twice, and unit is not run.  I'd like to make
>> sure the OpenStack charms are in line with any established Makefile
>> convention.  Is there a reference or doc for such a convention?
>>
>> I've seen 'unit_test' and 'functional_test' target names in use as well,
>> and I quite like those, as they leave no question as to purpose.
>>
>> To work around the variations we've seen across charms, server team's
>> OSCI (OpenStack CI charm testing) ignores make target names, and instead
>> parses the Makefile, looking for the right "thing-to-do," then execs the
>> target found.  Bear in mind that OSCI isn't intended to be a replacement
>> for general charm QA, rather it is an intense safety trigger for the
>> OpenStack charm developers.  We also want these charms to succeed in Juju
>> QA / CI.
>>
>> Input and advice are much appreciated!
>>
>> Many thanks,
>>
>>
>> Ryan Beisner
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Reply via email to