Revision file on charms
stuart.bishop at canonical.com
Mon Sep 8 15:51:28 UTC 2014
On 8 September 2014 22:00, Simon Davy <bloodearnest at gmail.com> wrote:
> On 8 September 2014 15:40, Matt Bruzek <matthew.bruzek at canonical.com> wrote:
>> 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 <stuart.bishop at canonical.com>
More information about the Juju