On Fri, Jun 17, 2016 at 2:10 AM, Jay Wren <[email protected]> wrote:
> 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. > Thanks, Jay. There is some potential in that. I think it'd be worth discussing some k:v norms around this that we can all gather around. Then, perhaps more importantly, how that info will persist in the places where it needs to be observed, such as: charm store ui, a pulled charm, and the resulting deployments. > > -- > 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 > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
