Created by Brad Crittenden on 2013-06-18 and last modified on 2013-06-18
Get this branch:
bzr branch lp:~bac/charms/precise/juju-gui/expose-cookies
Only Brad Crittenden can upload to this branch. If you are Brad Crittenden please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Brad Crittenden

Recent revisions

70. By Brad Crittenden on 2013-06-18

Bump rev

69. By Brad Crittenden on 2013-06-18

Expose 'use-analytics' via the charm.

68. By Francesco Banconi on 2013-06-12

Charm test improvements.

This branch includes some improvements to
the charm testing infrastructure:

Strengthened the Juju implementation check by
introducing a new juju_version helper function.

Do not require the branch to be named "juju-gui"
anymore: the charm can be tested and deployed from
an arbitrary branch.

Updated documentation.

Added the .lbox.check file: now, before
proposing/submitting at least the lint check
and the unit tests must pass.

R=teknico, j.c.sackett

67. By Nicola Larosa on 2013-06-12

Add AGPL license and headers.

Add headers pointing to the AGPL license to almost all files,
and add the license text itself.

Sorry for the size, it's just comments, no behavior change.

R=matthew.scott, frankban

66. By Francesco Banconi on 2013-06-11

Fix the charmworld URL default value.

Missing trailing slash.


65. By Francesco Banconi on 2013-06-10

Replace jitsu test with juju-test.

This branch makes juju-test the default test runner
for both the unit tests and the charm functional tests.

The charm test suite now supports both pyJuju and juju-core.

The tests dependencies are now installed in a virtualenv that
is automatically created and updated by the first test
executable (00-setup). This way we don't require the user
to install all the packages, and, moreover, we make the tests
ready to be run in the charm testing infrastructure.

When the charm is deployed during tests, a temporary repository
is created where the charm is copied and then deployed.
This way we achieve two important goals:
- the developer is not forced to manually set up a local
Juju repository where to branch the Juju GUI;
- the charm can be deployed even if it contains a virtualenv, i.e.
a directory with absolute symlinks (that's because the .venv dir
is not copied in the temp repo).

The tests/helpers.py and tests/deploy.py files will be eventually
replaced by similar tools provided by the juju testing harness.

Updated the documentation where required.

Fixed unit tests exit code.

Common commands (test/lint/clean etc.) can now be easily run
using make.

Nice to have, not included in this branch:
  - collect deployment test logs;
  - reintroduce a way to test the charm specifying a
    different juju-gui-source;
  - do not require the branch to be named "juju-gui".

PS: sorry for the diff, well over 1k loc :-/


64. By Nicola Larosa on 2013-06-06

Fix backend unit tests.

Make the backend unit tests not expect any extra repositories.

R=frankban, bac

63. By Brad Crittenden on 2013-06-04

[TRIVIAL] Add .lbox for specifying the target


62. By Brad Crittenden on 2013-06-04

Fix the discrepancy between dev and rel branches.

Changes that should've been submitted to the development branch of the gui
(lp:~juju-gui/charms/precise/juju-gui/trunk) were instead merged into the
release branch (lp:charms/juju-gui).

This branch merges those changes back into devel for on-going work. The
premature release will remain in place.


61. By Francesco Banconi on 2013-06-03

Take the juju API address from the environment

The charm now tries to retrieve the juju API
address from the hook context before parsing
the machiner agent file.

This way we take advantage of a change in juju-core
currently in review, which introduces the corresponding


Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
This branch contains Public information 
Everyone can see this information.