-
-
Notifications
You must be signed in to change notification settings - Fork 499
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
canned postgresql #98
Conversation
canned/postgresql.go
Outdated
return nil, err | ||
} | ||
|
||
for { |
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.
I guess this is because the postgres container "bounces" and logs the "database system is ready to accept connections" twice?
In the java testcontainer that's handled by having the Wait code have a state and wait for it twice.
I think I prefer this, as it keeps the Waits simple
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.
Yes, I don't understand why the Postgres container is doing that, but basically the process gets restarted, so you'd have to wait for the second "database system is ready to accept connections"
. So I tried to mimic the Java implementation for the generic JDBC containers.
I realised though, the wait strategy I put there is basically pointless? 🤔
I have another proposal to make the same wait process into a proper SQLStrategy
wait strategy.
wait/sql.go
Outdated
for { | ||
_, err := db.ExecContext(ctx, "SELECT 1") | ||
if err != nil { | ||
time.Sleep(500 * time.Millisecond) |
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.
Maybe there should be a max wait time, just in case?
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.
Whoops... you're right. I completely forgot.
I did the same as in wait/log.go
now. Also added the fluent builders as in LogStrategy for consistency
This is related to the work @giorgioazzinnaro is doing here #98 . Now you can declare how many times a log line should appear before having the container declared as ready. Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
This is related to the work @giorgioazzinnaro is doing here #98 . Now you can declare how many times a log line should appear before having the container declared as ready. Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
This is related to the work @giorgioazzinnaro is doing here #98 . Now you can declare how many times a log line should appear before having the container declared as ready. Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
This is related to the work @giorgioazzinnaro is doing here #98 . Now you can declare how many times a log line should appear before having the container declared as ready. Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
Sweet! Do you mind to add a godoc example as well?! Thanks a lot |
Yeah, I think that'd be useful! Will do over the weekend. As for the wait strategy, do you guys think we should keep the SQL client or go back to LogStrategy with multiple occurrences? |
@giorgioazzinnaro I've created a PR to your branch to add support for custom dockerfiles borgoat#1 |
Allow using custom dockerfile
I merged #105 #98 and #102 in the master of my fork to see how the godoc turns out, so here it is: Any other suggestions on how to proceed with this? |
It would be great to have this feature being merged and released |
This looks pretty good. What's blocking it from being merged? Glad to help if I can. |
Hey folks, just wanted to check again how's the progress with this PR? If there's anything I can do to help, let me know! |
Looks like a file named
|
I guess we need to include the maintainers again in the discussion, I think we were still stuck at understanding whether it's sensible to throw all the possible canned containers in the root module, or rather create a go module for each of them (so that pulling the main module won't bring along a dependency on Redis, Postgres, MySQL, etc ... clients). Since we last discussed this the support for Go modules has greatly improved @gianarb @mdelapenya what's your opinion on this? |
We started this PR, which could be the seed for modules: #618 It creates examples to be consumed by the website, but turning them into modules would be a matter of adjusting the templates. |
Ciao @gianarb @alde @mraerino
I took inspiration from #59 also to address #19
I tried to implement some of the suggestions by @mraerino in #59 ..
Let me know if I should change anything else!