-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds pluggable wait strategy, and HTTP(S) implementation. #133
Adds pluggable wait strategy, and HTTP(S) implementation. #133
Conversation
636f525
to
6d257cd
Compare
/** | ||
* The approach to determine if the container is ready. | ||
*/ | ||
protected WaitStrategy waitStrategy; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Set to Wait.defaultWaitStrategy()
and mark @ NonNull on the field and withWaitStrategy
parameter? Then no need for a null check at time of use...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wanted to avoid additional assignment but happy to change if you feel strongly :)
Thanks for this! Just a few comments so far, but looking good! BTW the CI builds have both failed on the Virtuoso container module - it's possibly unrelated but I'm looking into it... |
@rnorth the tests failed because I rebased after pushing ;-) Have switched to pushing additional commits now to track comments above. |
Aha! No worries then :)
|
*/ | ||
protected void waitUntilContainerStarted() { | ||
getWaitStrategy() | ||
.forContainer(this) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.forContainer()
should return new instance or should be removed in favour of an argument in waitUntilReady
and stateless strategies.
Motivation - current implementation creates a false positive feeling that we can re-use existing strategy for different containers, but we can't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could fix this by moving the container assignment to the constructor or, alternatively, throwing an IllegalStateException
on calling forContainer
more than once.
@rnorth thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
constructor sounds fine for me 👍
Ah, no, on second thought that would break chaining, as the container ref isn't initialised yet when declaring the class rule field. Might just make the |
FWIW I'll accept this PR with only Travis CI passing, as the CircleCI builds are not receiving the patch on master to disable Virtuoso build. FYI @outofcoffee, when you're ready. |
78fab09
to
7640781
Compare
Tests failing because of #140 |
7640781
to
ab92e37
Compare
@rnorth as discussed; Travis build is passing, but Circle still having issues. |
…readiness using arbitrary logic. Adds HTTP(S) wait strategy to wait for a particular endpoint to be available.
ab92e37
to
1613efe
Compare
Looks good to me - will merge. |
Purpose
This PR adds a pluggable wait strategy, to enable containers to be checked for readiness using arbitrary logic.
It also adds an HTTP(S) wait strategy to wait for a particular endpoint to be available.
Implementation
waitForListeningPort(...)
logic into its own class.Examples
Wait for 200 OK:
Wait for arbitrary status code on an HTTPS endpoint: