Question for cosmetic and understandability of breadcrumbs in github

[Jay Wren]

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.

--
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160617/cecf0a4b/attachment.html>