If it helps, the charm set command supports arbitrary key values to be stored in extra-info in the charm store.
e.g. $ charm set cs:~evarlast/trusty/parse-server-0 layer-x=rev1 layer-y=rev2 Then this will be displayed in extrainfo: $ charm show cs:~containers/trusty/swarm extra-info extra-info: layer-x: rev1 layer-y: rev2 After pushing, you could use set to save the revisions of what was used to build the charm. -- Jay On Thu, Jun 16, 2016 at 8:51 PM, Charles Butler < [email protected]> wrote: > Greetings, > > I deposit many of my layers in GitHub, and one of the things I've been > striving to do is keep tag releases at the revisions i cut a charm release > for a given channel. As we know, the default channel is seen by no-one, and > runs in increments of n+1. > > My prior projects i've been following semver for releases, but that has > *nothing* in terms of a breadcrumb trail back to the store. > > Would it be seen as good practice to tag releases - on the top most layer > of a charm - with what charm release its coordinated with? > > Given the scenario that i'm ready to release swarm, and lets assume that > to date i haven't tagged any releases in the layer repository: > > charm show cs:~containers/trusty/swarm revision-info > revision-info: > Revisions: > - cs:~containers/trusty/swarm-2 > - cs:~containers/trusty/swarm-1 > - cs:~containers/trusty/swarm-0 > > I see that i'm ready to push swarm-3 to the store: > > git tag 3 > git push origin --tags > > I can now correlate the source revision to what i've put in my account on > the store, but this does not account for promulgation (which has an > orthogonal revision history), and mis-match of those id's. > > I think this can simply be documented that tags track > <<username>>/<<charm>> pushes, and to correlate source with release, to use > the method shown above to fetch release info. > > Does this sound useful/helpful or am I being pedantic? (I say this because > Kubernetes touches ~ 7 layers, and it gets confusing keeping everything up > to date locally while testing, and then again re-testing with > --no-local-layers to ensure our repositories are caught up with current > development work. (Cant count the number of open pull requests hanging > waiting for review because we've moved to the next hot-ticket item) > > All the best, > > Charles > -- > Juju Charmer > Canonical Group Ltd. > Ubuntu - Linux for human beings | www.ubuntu.com > Juju - The fastest way to model your service | www.jujucharms.com > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
