No, there was discussion on a method of specifying "deploy this bundle using all development channel charms" but since unpublished isn't a real channel it doesn't work here. As John says, you get a revision but then you have to update to that revision. Our openstack team has done some work to generate bundles based on charms tossed at it. I wonder if it'd be helpful here. I'm cc'ing in Ryan who might have more details.
On Wed, Jun 15, 2016 at 10:13 AM John Meinel <[email protected]> wrote: > I believe 'push' gives you a revision number, which the bundle can then > request. But that would need to recreate the bundle after each push. I > don't believe there is a handle for "latest unpublished version". > > John > =:-> > > On Wed, Jun 15, 2016 at 5:02 PM, Merlijn Sebrechts < > [email protected]> wrote: > >> Awesome! >> >> What's the recommended approach for the test bundles? These bundles >> should use the latest non-published dev version of the Charm. Is there a >> way to specify this in the bundle or should I recreate the bundle after >> each push? >> >> 2016-06-15 14:37 GMT+02:00 Rick Harding <[email protected]>: >> >>> That's exactly the plan we had in mind by breaking up charm push and >>> publish. Glad it's working for you. >>> >>> On Wed, Jun 15, 2016, 8:34 AM Merlijn Sebrechts < >>> [email protected]> wrote: >>> >>>> FYI: I found a better way to do the CI pipeline. Now I'm pushing the >>>> Charms to the store before testing and publishing them after testing. This >>>> means I'm not using local charms anymore. >>>> >>>> 2016-06-15 14:30 GMT+02:00 Marco Ceppi <[email protected]>: >>>> >>>>> It's possible, it has been a while since I checked the code but I'll >>>>> double check and get back to you. >>>>> >>>>> Marco >>>>> >>>>> On Wed, Jun 15, 2016, 2:32 AM Merlijn Sebrechts < >>>>> [email protected]> wrote: >>>>> >>>>>> Thanks, Marco! >>>>>> >>>>>> >>>>>> It's working now, but I'm getting 500 errors on our bundles. Is it >>>>>> possible that local charms are not supported? Since we're using cwr for >>>>>> our >>>>>> ci pipeline, all charms will be local... It would be nice if >>>>>> svg.juju.solutions could just render blank charms when it receives a >>>>>> bundle >>>>>> with local charms. >>>>>> >>>>>> This is one of our bundles: >>>>>> https://github.com/IBCNServices/tengu-charms/blob/master/bundles/hauchiwa-testbundle/bundle.yaml >>>>>> >>>>>> >>>>>> >>>>>> Kind regards >>>>>> Merlijn Sebrechts >>>>>> >>>>>> 2016-06-14 21:33 GMT+02:00 Marco Ceppi <[email protected]>: >>>>>> >>>>>>> Hi Merlijn, >>>>>>> >>>>>>> Sorry for the outage. Apparently the cloud is an ephemeral world. We >>>>>>> deploy svg.juju.solutions from the charm store >>>>>>> https://jujucharms.com/u/marcoceppi/charm-svg/3 but the cloud it >>>>>>> was on decided to turn off all the instances. I've redeployed it and >>>>>>> it's >>>>>>> back up now. >>>>>>> >>>>>>> I'll work on deploying it across a few regions and get a >>>>>>> loadbalancer in place to prevent this in the future. `juju add-unit` :) >>>>>>> >>>>>>> Marco >>>>>>> >>>>>>> On Tue, Jun 14, 2016 at 12:15 PM Merlijn Sebrechts < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Is svg.juju.solutions down? The "download svg" part of >>>>>>>> cloud-weather-report seems to be timing out. >>>>>>>> >>>>>>> >>>>>> >>>> -- >>>> Juju mailing list >>>> [email protected] >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/juju >>>> >>> >> >> -- >> Juju mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
