On 8 September 2014 22:00, Simon Davy <[email protected]> wrote: > On 8 September 2014 15:40, Matt Bruzek <[email protected]> wrote: >> José >> >> I just had a conversation about that with the Ecosystems team. You are >> correct, the revision file in the charm directory is no longer used and we >> can delete those files on future updates. > > So this is interesting, as we are looking to start using the revision > file more explicitly, as part of our automation. > > We deploy from local repositories, with charms in bzr, and one thing > we would like to explicitly know which *code* revision is currently > deployed in an environment. > > So we were thinking to have a pre-deploy step that did "$(bzr revno) > > revision" in each charm, just before deploy/upgrade. That way, the > revision reported by juju status gives us the exact code revision of > the the current charm. This would pave the way for us to diff a > current environment with a desired one and see what charms need > changing as part of a deploy. > > Does this make sense? Is there some other method of knowing the code > branch/revision a charm is currently running?
I think you are better off using a service configuration item to hold the version for now, at least until the dust settles. Juju is good about incrementing the number in the revision file when it needs to, which is probably not when you want it bumped. -- Stuart Bishop <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
