Another thing to bear in mind, as its a pain point at the ASF, git tags aren't immutable, so you really want to tie you commit to a tag (for ease of digestion) and a SHA hash for immutability.
-------------- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our Kickstart <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/> goal, but you can always help by sponsoring the project <http://www.meteorite.bi/products/saiku/sponsorship>) On 16 June 2016 at 23:54, Ryan Beisner <ryan.beis...@canonical.com> wrote: > 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 > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
