James Rawlings

> Last time I looked the rolling upgrades were broken for java projects; though its odd; they should all use the kubernetesApply stuff right? yeah that's right - ok cool...

in the [mavenTemplate{}](https://github.com/fabric8io/fabric8-pipeline-library/blob/master/vars/mavenTemplate.groovy) we can check to see if the job is a CI or CD pipeline [utils.isCI()](https://github.com/fabric8io/fabric8-pipeline-library/blob/master/src/io/fabric8/Utils.groovy#L100) and use a different pod template with different PVs mounted.

> Maybe extra bonus points would be to automatically rollback the Deployment change if the new version doesn't startup correctly? Would it be easy to leave a failed pod hanging...

> Can you describe this approach a bit more? Sure, the main problem of generating signed certs on minishift as I see it is a CA server needs to validate...

Agree with all that. I wonder if there's two ways forward here? 1. Short term generate a single (wildcard?) self signed cert that reduces the number of accepting browser tasks...

>This is where I am atm lost. I am a bit of a novice here, but my understanding is that the problem is not signing the certs. They are always...

Yeah saw that too although it's for public domains so we'd still have the same problem with nip.io when running locally on minishift.

+1 Is there already work on this? If so then I'd happily start looking at adding support for OpenShift OAuth too. We're looking at integrating Lets Chat with the fabric8...

Yeah I see your point. I'm trying to automatically setup the integration for Lets Chat, Taiga, Gogs and Hubot. I'm just trying to figure out the options at the moment...

And I think that would be great however as you say there's probably wider concerns but if a way could be figured out it would be awesome.