Automatic commit squashing

Hi everyone, Following on from the recent thread about commit squashing and commit message quality, the idea of automatically squashing commit at merge time has been raised. The idea is that the merge bot would automatically squash commits for a pull request into a single commit, using the PR

Re: TLS Terminated Etcd (If you use etcd this affects you)

Thanks for the feedback Jay and Casey, > We trust the network on which we run and we aren't getting and setting any sensitive data. > I value speed. I would continue to use a previous version of the charm. Perfectly reasonable response, but be aware that the older charm implementations aren't

Re: Juju 2.0-beta9 ETA

Hi folks, Due to a change I landed without fully thinking through the implications, the reverting of said change has pushed us out a day. I was trying to add consistency to the wire-protocol that Juju uses by changing the serialisation names. Thinking that we were still in the "we don't

Re: Juju 2.0-beta9 ETA

Hi folks, Due to a change I landed without fully thinking through the implications, the reverting of said change has pushed us out a day. I was trying to add consistency to the wire-protocol that Juju uses by changing the serialisation names. Thinking that we were still in the "we don't

Re: Is svg.juju.solutions down?

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

Charm push crashes when uploading big charms

Hi all I've hit a roadblock in setting up my CI pipeline. I have a charm with a Java sdk blob of ~200MB. Pushing this charm to the store causes the tool to crash. I put a bug report here: https://bugs.launchpad.net/juju/+bug/1592822 Juju resources would fix my problem, but then I'd need to move

Re: Is svg.juju.solutions down?

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 <

Re: Is svg.juju.solutions down?

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

Re: Is svg.juju.solutions down?

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 : > It's possible, it has been a while since

Re: Is svg.juju.solutions down?

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 wrote: > Thanks, Marco! > > > It's working now, but I'm getting 500 errors on our bundles. Is it > possible

Re: Is svg.juju.solutions down?

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