Question for cosmetic and understandability of breadcrumbs in github

[Merlijn Sebrechts]

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.butler at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160616/7bb37748/attachment.html>