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
