Question for cosmetic and understandability of breadcrumbs in github

Stuart Bishop stuart.bishop at canonical.com
Fri Jun 17 08:30:28 UTC 2016


On 17 June 2016 at 04:42, David Britton <david.britton at canonical.com> wrote:

> We are planning a tag for every push for the landscape-server and client
> charms, and bundles.  +1 on it being mentioned as a best practice (the same
> type of thing as when you release a version of any other software!).
> Though, I would recommend using the full charm store identifier eg:
> 'cs:~user/charm-3'.  Basically, the full standard out of the charm push
> operation.

This is what I'm doing with the PostgreSQL charm. I wrote up
https://github.com/stub42/ReactiveCharmingWorkflow to help polish my
processes as much as I could. I start with a layer, build to a
separate branch for testing, push that to the charmstore, tag it wth
the pushed revno and publish it to the dev channel. If tests pass, I
merge --no-ff the tested build into a release branch, publish it to
the release channel and tag it with both charmstore rev and semantic
version number. By doing the merges the right way, the change history
of the primary layer is visible on all three branches (the 'built'
commit has the source 'layer' commit as a parent, and 'git log' does
what you want). I have an issue open on the charmstore-client to make
parsing the pushed charmstore revno easier.

After doing the write up it became obvious that it is all still too
fiddly, so rather than polish it for publication I instead planed to
do some git plugins to smooth over the process (sketched out in the
'Future' section).

I'm mulling over how to handle dependant layers, and if we can get
them into the repo to solve the pinning problem and include their
change history. I haven't got this sketched out very far beyond some
vague thoughts that subtrees might be useful, and don't know if it is
at all practical. The build and publish process seems solid though,
and the 'manual' equivalent in my Makefile rules has been working well
for me. I want to get the basic build, push and publish plugins done
in the very near future.


> I also like the repo-info for traceability the other way around.  They solve
> a similar problem but depending on where you are looking are both useful.

Yes. This seems a good thing to have my proposed 'git charm-build' generate too.

-- 
Stuart Bishop <stuart.bishop at canonical.com>



More information about the Juju mailing list