Wait not working

[sverhagen]

As per the manual:

While starting a container is it possible to block [...]

• url is an URL which is polled periodically until it returns a HTTP 200 status code.
  [...]
• time is the time in milliseconds to block.

I observe that the wait does not work correctly:

• It marches on happily even for non-200 status codes (such as HTTP/1.1 405 Method Not Allowed)
• It marches on after the 30 seconds wait, without complaining

I think this is a regression since earlier 0.11 versions.

[rhuss]

Theres indeed a bug in the documentation. The idea is, that it wait until the return code is in the range [200...399] I don't know why it continues with 405, though.

The time watch is currently also implemented as an independent check (not as a timeout). Actually the wait check never breaks the build.

But this could it could be a good idea to let it croak on an timeout. Eg. the URL check could be refined to take the expected HTTP status code, the HTTP method to use (currently its always HEAD) and a timeout value after which is will throw an exception. Then, a time based wait is not needed anymore.

What do you think ?

[tdomzal]

I think wait check should brake the build on timeout.
I have used wait/time feature and was convinced its intention is to make sure container has started correctly. Was quite surprised it not the case and little bit of searching brought me here...

I think most useful combination would be:

• check URL periodically until non error response code is returned
• if given time pass - brake the build
• some default time is convenient - check should not hang the build completely if container is permanently not working as expected

Reason for this is that imho it is always better to build have an unambiguous result - either continue (if check URL confirmed container started) or fail (on timeout).

[sverhagen]

Yes, I was also under the impression that this is pretty much how it worked. For a while all my observations didn't even contradict my idea about this feature. And as a result I've stood in front of a small audience explaining it like this. We better start covering my <behind>...

[sverhagen]

So: fail if unexpected response code, or time expires with no response.

In other words: only proceed if expected response code within the configured time.

A while ago I thought that I cared about other response codes than 200, and I would then also have liked a regular expression to match the console output. But I've grown fond of the HTTP 200.

[sverhagen]

Do you think you'll have a chance to make this work in proper conjunction between the web service call and the timeout, it's still a concern in our build?

[rhuss]

As I'm now back from some conferencing, I will try to tackle this for the next release which I hope can get out next week.

[rhuss]

I fixed that now in that <time> is a real timeout if an <url> or <log> is present. If only <time> is specified it simply waits that many millis. 'hope that fits your expectations ;-)

'will be available in 0.12.0

[sverhagen]

Verified my use case:

[INFO] DOCKER> Starting container e1129e2d657c
[INFO] DOCKER> Creating and starting container e1129e2d657c [blahblah:0.1.0-SNAPSHOT] "blah"
[ERROR] DOCKER> Timeout after 30 ms while waiting on on url http://192.168.1.1:49200