lbox.check for automated testing on propose/merge

lbox.check for automated testing on propose/merge

That is all.

https://code.launchpad.net/~hazmat/charmworld/lbox-check/+merge/139503

(do not edit description out of merge proposal)

[hazmat, 2012-12-12 16:14:24]

Please take a look.

[rharding, 2012-12-12 16:39:17]

lgtm as a starting point, but have concerns over it replacing jenkins entirely.

https://codereview.appspot.com/6930057/diff/1/.lbox.check
File .lbox.check (right):

https://codereview.appspot.com/6930057/diff/1/.lbox.check#newcode2
.lbox.check:2: ./bin/nosetests --with-id -v -s -x charmworld
So this forces a make test before submit, but doesn't really do a clean
environment make check like jenkins does. If we go this route, I'd rather we
work to make this wipe/clean the environment with a distclean/check. Once we get
back to pip/virtualenv we can have it destroy/recreate/install the virtualenv in
whole and run the tests. I worry about forgetting to add deps to
requirements.txt, updates to the ini files, etc that don't get caught with a
simple make test.

[hazmat, 2012-12-12 17:35:52]

On 2012/12/12 16:39:17, rharding wrote:
> lgtm as a starting point, but have concerns over it replacing jenkins
entirely.
> 
> https://codereview.appspot.com/6930057/diff/1/.lbox.check
> File .lbox.check (right):
> 
> https://codereview.appspot.com/6930057/diff/1/.lbox.check#newcode2
> .lbox.check:2: ./bin/nosetests --with-id -v -s -x charmworld
> So this forces a make test before submit, but doesn't really do a clean
> environment make check like jenkins does.  If we go this route, I'd rather we
> work to make this wipe/clean the environment with a distclean/check. Once we
get
> back to pip/virtualenv we can have it destroy/recreate/install the virtualenv
in
> whole and run the tests. I worry about forgetting to add deps to
> requirements.txt, updates to the ini files, etc that don't get caught with a
> simple make test.

i'm not as concerned with the clean environment in this context, we're trying to
keep things fairly fluid for a developer, forcing a rebuild of the dev
environment doesn't really ensure the offline usage, and just adds weight/time
to the process. i'd also prefer not forcing a separate virtualenv per branch, vs
allowing a developer to use one for the project. 

things like missing deps/ini will likely get caught by other folks on the team. 

for the repeatable deploy testing, we'll have a charm for a staging environment
that can help ensure that.

ie. trying to avoid process where an informal approach works as well, while
still having the ability to rigorously test the deploy scenario.

all that said perhaps the .lbox.check should just be doing make test instead of
running nose directly.

[hazmat, 2012-12-12 18:06:50]

Please take a look.

[rharding, 2012-12-12 18:12:22]

lgtm with docs update noted.

https://codereview.appspot.com/6930057/diff/9001/Makefile
File Makefile (left):

https://codereview.appspot.com/6930057/diff/9001/Makefile#oldcode26
Makefile:26: $(INI) deps \
Ok, so I'm cool with removing deps from install but the docs (docs/index.rst)
should be updated to point out that setup is two steps, make deps && make
install to get going.

[hazmat, 2012-12-12 18:25:16]

*** Submitted:

lbox.check for automated testing on propose/merge

That is all.

R=rharding
CC=
https://codereview.appspot.com/6930057