Add integration test to create and deploy of example application

[agajdosi]

As discussed in #548 we need to test basic functionality and usage of OpenShift as part of quick smoke test which basic.feature is going to be.

Simple plan for this issue is to make sure with integration tests that an example application can be deployed on OpenShift. However it will be good to further expand this plan by more scenarios - check that application can be deleted, etc.

[amitkrout]

Considering this as a first call for s2i ruby-ex example application deployment, the basic scenario steps would be like

1. oc login
2. Create a new namespace 
3. deploy the app
4. oc logs for the deployed app
5. Delete namespace
6. logout

However here the problem is with the readiness of the deployment environment. So sleep is added before each scenario steps to handle the readiness. IMO this is not the efficient way to handle this. There should be a better way to handle readiness.

For initial implementation considering sleep as a solution, then adding sleep time amount will be a challenge. For example : Just after minishift start, running oc login command throws error and after sometime the same command oc login will work as expected.

Now the question is how much sleep time we should put before each step to make the whole deployment ideal/optimized wrt sleep time.

This scenario i have executed successfully.

sleep for 120sec
oc login
sleep for 10sec
Create a new namespace 
sleep for 10sec
deploy the app
sleep for 30sec
oc logs for the deployed app
sleep for 5sec
Delete namespace
sleep for 5sec
logout

Please share your thoughts

[agajdosi]

@amitkrout

For example : Just after minishift start, running oc login command throws error and after sometime the same command oc login will work as expected.

Then we should add the OpenShift part right before "Stopping minishift" scenario, so previous scenarios will make some time for oc, but still it won't go under 100sec I guess. Other sleeps seem to be quite short.

IMO this is not the efficient way to handle this. There should be a better way to handle readiness.

Would be nice to come up with some try-retry(-timeout) concept, but right now I am not sure how to design it well so we won't repeat ourself in each step definition. Only idea I have right now is to create a step definition with match try for x seconds: "(.*)", which will then call a function tryRetry. This function will accept arg1=matched string, arg2=timeout. In this function we will then handle the work around matched string which will later call a normal function of step definition. But still we will repeat regex match on 2 places - in func FeatureContext(s *godog.Suite) and then in func tryRetry()...

[amitkrout]

@agajdosi for #774, same function implimentation executingRetryingTimesWithWaitPeriodOfSeconds(command string, retry, sleep int) is merged by @hferentschik. Will reuse it.

[hferentschik]

Merged via pull request #796