Makefile target names
Ryan Beisner
ryan.beisner at canonical.com
Thu Jan 22 14:57:24 UTC 2015
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.saller at 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.beisner at 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 at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150122/06b0ffbf/attachment.html>
More information about the Juju
mailing list