Question for cosmetic and understandability of breadcrumbs in github

[Charles Butler]

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.sebrechts at 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.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
>>
>> --
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160616/3d4fab9b/attachment.html>