Question for cosmetic and understandability of breadcrumbs in github

Merlijn Sebrechts merlijn.sebrechts at gmail.com
Thu Jun 16 20:54:01 UTC 2016


Yep, seems like something useful!

2016-06-16 22:48 GMT+02:00 Charles Butler <charles.butler at 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.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/542c7074/attachment.html>


More information about the Juju mailing list