On 17 June 2016 at 04:42, David Britton <[email protected]> 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 <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
