Issue Overview
Creates an integration with Fabric8 plugin because when Fabric8 maven plugin is run it takes the default namespace configured (or the one that it is active in oc configuration) and do some stuff like creating ImageStreams or configuring builds.
The problem is that when running with Cube, you need to specify the namespace where Fabric8 has done all the configuration steps. That's fine in most cases, but if you want to use the random namespace generation provided by Cube, then the test will fail because this namespace created by Cube was not the one configured by Fabric8.
Expected Behaviour
The solution would be integrating Fabric8 plugin with Cube by either:
- we can re-use logic of fabric8-maven-plugin to generate those files create s2i image and register it in openshift registry this can be done under the hood based on e.g
@AutogenerateOpenshiftResources annotation put on the test class
- we can provide Shrinkwrap descriptors so you can either create default files like fmp does but also open it up for customization "shrinkwrap style "this would mean we have to flesh out what kind of
@Deployment methods we would like to have to make it simple and powerful enough
My recommendation would be as first try, the first approach.
Current Behaviour
No integration
Additional Information
This bug comes from #743
Issue Overview
Creates an integration with Fabric8 plugin because when Fabric8 maven plugin is run it takes the default namespace configured (or the one that it is active in
occonfiguration) and do some stuff like creating ImageStreams or configuring builds.The problem is that when running with Cube, you need to specify the namespace where Fabric8 has done all the configuration steps. That's fine in most cases, but if you want to use the random namespace generation provided by Cube, then the test will fail because this namespace created by Cube was not the one configured by Fabric8.
Expected Behaviour
The solution would be integrating Fabric8 plugin with Cube by either:
@AutogenerateOpenshiftResourcesannotation put on the test class@Deploymentmethods we would like to have to make it simple and powerful enoughMy recommendation would be as first try, the first approach.
Current Behaviour
No integration
Additional Information
This bug comes from #743