We are planning a tag for every push for the landscape-server and client charms, and bundles. +1 on it being mentioned as a best practice (the same type of thing as when you release a version of any other software!). Though, I would recommend using the full charm store identifier eg: 'cs:~user/charm-3'. Basically, the full standard out of the charm push operation.
I also like the repo-info for traceability the other way around. They solve a similar problem but depending on where you are looking are both useful. On Thu, Jun 16, 2016 at 2:54 PM, Merlijn Sebrechts < [email protected]> wrote: > Yep, seems like something useful! > > 2016-06-16 22:48 GMT+02:00 Charles Butler <[email protected]>: > >> I was actually talking to beisner about this in Irc and the open stackers >> are putting a report in their artifacts with the repository information. >> >> >> https://api.jujucharms.com/charmstore/v5/~openstack-charmers-next/xenial/neutron-gateway/archive/repo-info >> >> I think I like this better. >> >> We are generating a manifest of the other layers but I'm not certain we >> are storing any commit hash info in that manifest. I don't think we are. >> >> But it would give me a nice trail to follow. >> >> On Thu, Jun 16, 2016 at 4:42 PM Merlijn Sebrechts < >> [email protected]> wrote: >> >>> Well, Charles, I must admit that I'm a bit lost. There's some lingo in >>> this email I don't quite understand, and it's quite late on my side of the >>> globe ;) >>> >>> What I understand you want: You have a Github repo that contains the top >>> layer of a Charm. Each tag in that repo corresponds to the revision of the >>> charm build from that layer. Is this correct? >>> >>> This would allow you to see what Charm corresponds to what layer version. >>> >>> I don't quite understand how this would solve your kubernetes problem. >>> Don't you want this information about every layer instead of just the top >>> one? Is this something 'charm build' would be able to do automatically? It >>> gets the layers from a repo so it might be able to put that info >>> (repo/commit) in a log somewhere? >>> >>> 2016-06-16 19:51 GMT+02:00 Charles Butler <[email protected]> >>> : >>> >>>> 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 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 > > -- David Britton <[email protected]>
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
