Git tagging is certainly helpful to developers, so a big +1 to that for git-based projects.
I think there is also a definite need to tie a specific charm store charm revision to its exact place and "time" of origin. Charms which are pushed into the charm store (and the deployed charms) are a bit mysterious in terms of source code origin and revision level. The two relevant `charm set` tagging mechanisms (homepage and bugs-url) are helpful, and we do populate that info. But to get the granularity of identification for our desired level of support, some other "thing" is necessary. This week, we started injecting repo-info files [1] into OpenStack charms [2] just ahead of the push and publish automation in our git/gerrit CI pipeline. The repo-info file will only ever exist in pushed charms, never in the charm source code repos. From the user and support perspective, this ensures that the code origin and revision info is in the user's possession at all times, and that it flows through and exists on-disk in all units in the deployed models. Many moons later, if a bug is raised or a support call comes in, there will be a way to know exactly what charm code is in play, down to the repo and commit hash level. Combining both a git tag breadcrumb and a repo-info breadcrumb would really squash the code origin mystery from any vantage point. I'm not certain we can tag commits via the upstream OpenStack cgit:gerrit workflow, but we'll look into it. On another plane: I've seen some charm metadata buckets which appear to accept arbitrary data bits. It may be useful to also stash repo/commit type of info there, but I've not explored that much at all. [1] https://api.jujucharms.com/charmstore/v5/~openstack-charmers-next/xenial/neutron-gateway/archive/repo-info [2] https://jujucharms.com/u/openstack-charmers-next/neutron-gateway/xenial Cheers! Ryan On Thu, Jun 16, 2016 at 4:42 PM, David Britton <david.brit...@canonical.com> wrote: > 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 < > merlijn.sebrec...@gmail.com> wrote: > >> Yep, seems like something useful! >> >> 2016-06-16 22:48 GMT+02:00 Charles Butler <charles.but...@canonical.com>: >> >>> 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 < >>> merlijn.sebrec...@gmail.com> 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 <charles.but...@canonical.com >>>> >: >>>> >>>>> 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 >>>>> Juju@lists.ubuntu.com >>>>> 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 >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> > > > -- > David Britton <david.brit...@canonical.com> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
