Closed bac closed 8 years ago
Sweet, +1!
:+1: though I am surprised to find that we are evidently copying releases to master. I thought we weren't doing that yet for some reason.
Mind you, I'm pleased that we are.
Things seemed to work nicely until one error killed it all.
no previously-included directories found matching 'docs/_build'
Successfully downloaded Mako MarkupSafe Paste PasteDeploy Pygments WebOb argparse convoy pyramid-mako pyramid repoze.lru six translationstring venusian waitress wsgiref zope.deprecation zope.interface Cleaning up... make[2]: Leaving directory '/home/jrwren/src/charms/juju-gui/src/juju-gui' make[1]: Leaving directory '/home/jrwren/src/charms/juju-gui/src' cp -r src/juju-gui/dist/* releases cp -r src/juju-gui/collected-requirements/* jujugui-deps cp: target ‘jujugui-deps’ is not a directory Makefile:78: recipe for target 'package' failed make: *\ [package] Error 1
:+1: QA looks good
:shipit:
With the addition of the 'make package' target, the version of the jujugui-charm that we keep in version control no longer has all of the dependencies required by the juju gui and doesn't have the package for the gui. Instead, running
make package
will fetch the latest repo of juju gui from github and build from the master branch, copying the tarball and all dependencies into place. Once done,charm2 upload
can be used and the fat charm will be uploaded with the temporary files (releases/jujugui-<latest>.bz2
andjujugui-deps
) uploaded.This approach is a spike to see if it is a better way to manage fat charms. There are fewer duplications across codebases, so that's a good thing. Publishing a new charm release becomes simply:
QA: First, set environment variables to talk to jujugui.org so the real charmstore isn't polluted.
export JUJU_CHARMSTORE=http://api.jujugui.org/charmstore
You can then try uploading and publishing the charm and deploying from jujugui.org.