Question for cosmetic and understandability of breadcrumbs in github

[Ryan Beisner]

On Fri, Jun 17, 2016 at 2:10 AM, Jay Wren <jay.wren at canonical.com> wrote:

> If it helps, the charm set command supports arbitrary key values to be
> stored in extra-info in the charm store.
>
> e.g.
>
> $ charm set cs:~evarlast/trusty/parse-server-0 layer-x=rev1 layer-y=rev2
>
> Then this will be displayed in extrainfo:
>
> $ charm show cs:~containers/trusty/swarm extra-info
> extra-info:
>   layer-x: rev1
>   layer-y: rev2
>
> After pushing, you could use set to save the revisions of what was used to
> build the charm.
>

Thanks, Jay.  There is some potential in that.  I think it'd be worth
discussing some k:v norms around this that we can all gather around.  Then,
perhaps more importantly, how that info will persist in the places where it
needs to be observed, such as:  charm store ui, a pulled charm, and the
resulting deployments.



>
> --
> Jay
>
> On Thu, Jun 16, 2016 at 8:51 PM, Charles Butler <
> charles.butler at canonical.com> wrote:
>
>> 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 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/20160617/06a6dec0/attachment.html>