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
