I think that it's important that we have tooling (i.e., bundletester)
that sets up a (consistent) environment that is exactly the same as
what the automated test runner uses (i.e., a fresh container or vm in
which the tests are run) and that charm authors and reviewers alike
use it. With that,
Lots of good feedback here with regard to how we want to manage it.
I'm personally +1 on having a Makefile in my charm that handles these
things, but was unsure if this was our defacto recommended path to
completion.
Thanks for such an active and rapid response on the thread.
On Tue, Jan 20,
Well there are two notions of testing, unit_test and functional_test one is
largely more expensive than the other. Outside of that test-depends is a
good one. Whatever it is we should identify those so we can make sure
bundletester is updated to sniff these targets out (if this is the route we
A Makefile that has a target to install dependencies suffices, but I think
suggested conventions are still helpful. For example, in my case I prefer
python virtualenvs over system packages.
Once you establish some conventions (perhaps even just documentation
conventions), A charmer can document
On Tue, Jan 20, 2015 at 05:58:24PM +, Marco Ceppi wrote:
I don't see how a Makefile in a charm doesn't resolve this issue.
+1 on some standard published Makefile targets. We already have some
that are highly recommended:
- test
- lint
Maybe:
- test-depends or depends # to
Greetings,
If you work on charms in any capacity: this affects you, and I would love
to have your feedback.
While working the review queue I've encountered a few charm merges that are
failing our testing infrastructure due to missing dependencies. This also
has implications that reach beyond our
I don't see how a Makefile in a charm doesn't resolve this issue. As long
as we define what targets a user should create in the Makefile, the
Makefile can then do everything required: create a virtualenv and install
deps, install ruby and execute bundler, npm for node, etc. Since charms are
so
We are striving to test charms against all substrates and architectures
juju supports; and are nearing completion for that goal. Manual provider is
not currently tested AFAIK but will likely be in the future.
On Tue Jan 20 2015 at 7:41:27 PM Andrew Wilkins
andrew.wilk...@canonical.com wrote:
On Wed, Jan 21, 2015 at 8:24 AM, Michael Nelson
michael.nel...@canonical.com wrote:
For eg., if it was a python charm that needed some python packages:
.virtualenv:
virtualenv .virtualenv
.virtualenv/bin/pip install -r test_requirements.txt
test: .virtualenv
On Wed, Jan 21, 2015 at 5:17 AM, David Britton
david.brit...@canonical.com wrote:
On Tue, Jan 20, 2015 at 05:58:24PM +, Marco Ceppi wrote:
I don't see how a Makefile in a charm doesn't resolve this issue.
+1 on some standard published Makefile targets. We already have some
that are
10 matches
Mail list logo
