I think it would be best to reserve "auto publishing" to the edge channel. That's exactly what edge is for, to receive the latest builds from whatever process you are automating with the least amount of impact to existing installations. From there it's simple to promote the charm through the channels.
This leaves the "lever pulling" to a manual process of a human once the application has been properly vetted and QA'd. You could reasonably set this up so edge is always possibly broken, but if the tests pass, it goes into Beta/RC appropriately. (If you're installing from edge, you agree to file bugs and deal with the shenanigans right?) Examples below: charm release cs:~wethecharmers/mything-404 --channel=beta and so on.. and of course, only push to --stable once you've verified that both forward-looking upgrades work as expected, and it's so stable it's boring. charm release cs:~wethecharmers/mything-404 --channel=stable My 2 cents. All the best. Charles Charles Butler <charles.but...@canonical.com> - Juju Charmer Come see the future of modeling your datacenter: http://jujucharms.com On Mon, Dec 12, 2016 at 6:38 AM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > I'm just not sure what the best approach would be. My idea is that our CI > system will push directly to stable. However, I think it's best if the > charms are only pushed to stable when both the Charm tests and bundle tests > succeed. So maybe after charm tests, the charms are pushed to edge, and > when the bundle tests succeed both the bundles and the charms are pushed to > stable? > > 2016-12-12 11:17 GMT+01:00 Konstantinos Tsakalozos < > kos.tsakalo...@canonical.com>: > >> This workflow sounds reasonable. One question, why are you using only the >> edge channel? >> >> Thanks >> >> On Fri, Dec 9, 2016 at 10:13 PM, Merlijn Sebrechts < >> merlijn.sebrec...@gmail.com> wrote: >> >>> The workflow that we'd like to have is very similar to what you do with >>> the charms. The first steps are already possible with `bundle-cwr-ci`: >>> >>> - If a new charm version is committed, run the tests of that charm. >>> - If the tests succeed, push the charm to edge. >>> >>> We save our bundles on Github with revision-less charm urls. A push of a >>> charm to the edge channel should trigger a job that does the ci for the >>> bundle: >>> >>> - Add the latest revision to all revision-less charm urls. (If they >>> do have a revision specified, leave them be.) >>> - Run bundletester on the resulting bundle. >>> - If tests succeed, push the bundle to edge. >>> >>> What do you think of this workflow? >>> >>> Our workflow in the past was a lot more complex, but moving to MAAS >>> allowed us to greatly simplify it. >>> >>> >>> >>> 2016-12-09 5:33 GMT-05:00 Konstantinos Tsakalozos < >>> kos.tsakalo...@canonical.com>: >>> >>>> Hi Merlijn, >>>> >>>> Building/testing/releasing bundles from the CI is in our future tasks. >>>> >>>> Some time ago you posted on this list a script to update bundles in >>>> light of charm updates. We will have to take a closer look in the way >>>> bundles are handled in your case. Any feedback is much appreciated. >>>> >>>> Thanks, >>>> Konstantinos >>>> >>>> On Fri, Dec 9, 2016 at 4:52 AM, Merlijn Sebrechts < >>>> merlijn.sebrec...@gmail.com> wrote: >>>> >>>>> This is awesome! >>>>> >>>>> > I have a nasty habit of committing straight to master, so bear with >>>>> us as development is moving fast at the moment. >>>>> >>>>> If only you could have a CI system to test your bundles >>>>> automatically... ;) >>>>> >>>>> 2016-12-08 19:36 GMT-05:00, Kevin Monroe <kevin.mon...@canonical.com>: >>>>> > Hi Juju! >>>>> > >>>>> > From Matrix [0] to Review Queue [1] to Amulet [2] to Charm Author >>>>> Workflows >>>>> > [3], you'd think December was the month we all remembered the >>>>> importance of >>>>> > software testing. There are oodles of test tools for >>>>> charms/bundles, and >>>>> > if you know about all of them, you're probably putting out >>>>> thoughtful, >>>>> > well-tested charms (thanks stub!). >>>>> > >>>>> > One thing that we've found missing is a nice charm CI/CD system that >>>>> > leverages these tools to automatically give developers confidence in >>>>> their >>>>> > code and handle the release cycle from a source repo to the charm >>>>> store, >>>>> > soup to nuts. Wouldn't it be nice if you could commit a charm >>>>> update to >>>>> > github and automatically have Cloud Weather Report kick off Jenkins >>>>> jobs on >>>>> > all your clouds, which in turn called Bundletester to handle >>>>> deployment, >>>>> > which in turn called Amulet and Matrix to run specific tests? >>>>> Taking it a >>>>> > step further, it'd be nice if that system could automatically push >>>>> > charms/bundles to your edge channel (if their tests pass), and if >>>>> you tag >>>>> > source with a release tag, build/test/release it to your stable >>>>> channel. >>>>> > >>>>> > This kind of system is what the Big Software team has been working on >>>>> > recently, and we're open to feedback! Our goal is to deliver a >>>>> system (as >>>>> > a bundle) that answers the question, "how should I do CI/CD for my >>>>> charms >>>>> > and bundles?" We're also working on a variation that includes the >>>>> Review >>>>> > Queue -- it will eventually become the brains behind >>>>> > https://review.jujucharms.com and will be available for anyone >>>>> wanting a >>>>> > CI/CD + Source Review system in-house. >>>>> > >>>>> > If you're interested, development is happening at >>>>> > https://github.com/juju-solutions/bundle-cwr-ci. Have a look at >>>>> the readme >>>>> > for more details and let us know what you think. The bundle yaml >>>>> files are >>>>> > currently deployable, buy I have a nasty habit of committing >>>>> straight to >>>>> > master, so bear with us as development is moving fast at the >>>>> moment. Watch >>>>> > this space for updates on our progress. >>>>> > >>>>> > [0] - https://lists.ubuntu.com/archives/juju/2016-December/008260. >>>>> html >>>>> > [1] - https://lists.ubuntu.com/archives/juju/2016-December/008287. >>>>> html >>>>> > [2] - https://lists.ubuntu.com/archives/juju/2016-December/008288. >>>>> html >>>>> > [3] - https://lists.ubuntu.com/archives/juju/2016-December/008302. >>>>> html >>>>> > >>>>> > Thanks! >>>>> > -- >>>>> > Kevin Monroe >>>>> > >>>>> >>>>> -- >>>>> Juju mailing list >>>>> Juju@lists.ubuntu.com >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/juju >>>>> >>>> >>>> >>> >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
