-
-
Notifications
You must be signed in to change notification settings - Fork 500
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
feat: log docker info from compose #591
Conversation
if err != nil { | ||
p.Logger.Printf("failed getting information about docker server: %s", err) | ||
logger.Printf("failed getting information about docker server: %s", err) | ||
return |
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 noticed this if
was incomplete, as it should exit the function.
I wonder if we should raise an error here, as if the docker info failed, then we cannot continue. In the meantime, we can live with the return, as this function is called after the docker client creation, so it's expected using the client is healthy
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.
LGTM, the follow up idea sounds like a good plan 👍
@@ -22,6 +23,7 @@ const ( | |||
envComposeFile = "COMPOSE_FILE" | |||
) | |||
|
|||
var composeLogOnce sync.Once |
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.
oh, such a cool feature in Go 😮
What is this PR doing?
This PR extracts the function to log the docker info command from the provider to a helper method, so that it can be reused when creating a compose instance.
This new func recieves a Go context, a Docker client and the logger to be used
Finally, I noticed the existing logServerInfo function was incorrect in the flow: if an error occurred while getting the Info, the code did not exit the function, continuing with a wrong and empty message.
Why is it important?
We added the log info for the generic containers, but did not add it to the compose ones. After #476, now it's possible to spin up native compose containers from Go, without shelling out to the local binary, and this log was missing (the log was added way later than this PR was born)
Related issues
Follow ups
As part of #549, where we want to initialise resources once, we could improve the architectural design to have a single docker client for both container types (compose and generic), therefore we could simply log the server info in one single place, not in two as we have now.