-
Notifications
You must be signed in to change notification settings - Fork 13
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
Feature/container: new Container type & unit tests #340
Conversation
7a21585
to
a6edac2
Compare
799e332
to
6a04217
Compare
6a04217
to
e0e344e
Compare
I will review first thing tomorrow morning ;) @ilgooz If you want to start another dev from this branch before it's merged, you can start a new branch from your last commit ;) |
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.
Impressive PR 👍 one typo away from approval!
container/dockertest/client.go
Outdated
serviceInspectWithRaw chan serviceInspectWithRawResponse | ||
serviceRemove chan serviceRemoveResponse | ||
serviceLogs chan serviceLogsResponse | ||
contanerInspect chan containerInspectResponse |
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.
typo on contanerInspect
. Should be containerInspect
.
This typo is also at 3 other places.
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.
done
err := createSwarmIfNeeded(client) | ||
assert.Nil(t, err) | ||
} | ||
|
||
// TODO: this tests break other tests on my machine |
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.
Let's remove completely this file. I don't think we really need integration test on the createSwarm
functionality.
@antho1404 what do you think?
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.
Why would you want to remove it ? if the test is ok let's keep it, after I agree swarm tests are not absolutely necessary but I think it's still really good to keep these tests except if there is a good reason to remove them
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.
They are already commented out....
Let's remove the pollution.
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.
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.
my bad you're right
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'm removing core/container/client_test.go
file. @antho1404 are you ok with 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.
i think we should refactor our integration tests too #351. So maybe we should keep this one as a reminder to create an integration test from it.
} | ||
containers, err := client.ContainerList(context.Background(), types.ContainerListOptions{ | ||
ctx, cancel = context.WithTimeout(context.Background(), c.callTimeout) | ||
defer cancel() |
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.
is it ok to assign cancel
multiple time and call it using defer
?
Is defer
will really execute the 2 cancel or the last cancel 2 times?
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 it is ok. please see: https://play.golang.org/p/UeNDuSXbZz7
cmd/service/init.go
Outdated
if err != nil { | ||
log.Fatal(err) | ||
} | ||
defaultContainer = c |
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 think this is to initialize a defaultContainer
in the CLI but this file is the file for the command mesg-core service init
so that might not make sense to put it here but maybe more in the utils
where it's used
Also if it's only used one time in the service/utils#buildDockerImage
why not initialize it in this function directly
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 are going to remove these lines after service package refactored. *Container
will be initialized once and stored in the *Service
struct. I don't mind where to put this temporary code, want me to move to utils for now?
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 that would be good, I'm afraid to forget it here because it's not really related to this command
err := createSwarmIfNeeded(client) | ||
assert.Nil(t, err) | ||
} | ||
|
||
// TODO: this tests break other tests on my machine |
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.
my bad you're right
} | ||
|
||
// LastContainerList returns a channel that receives call arguments of last *Client.ContainerList call. | ||
func (t *Testing) LastContainerList() <-chan ContainerListRequest { |
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 don't like much the naming with Last
but i'm definitely not against it
"github.com/mesg-foundation/core/container" | ||
) | ||
|
||
var defaultContainer *container.Container |
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.
Isn't it better to create an instance every time we need it instead of creating it an init
function ?
It would be good to avoid init
functions that save a state.
This container is totally stateless so we can re-create it all the time and it will not change anything except some memory/cpu optimization but that are negligible for these features
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.
After daemon refactored, *Container
will be initialized only once and stored in the *Daemon
struct. Until the refactor we have to initialize a Container type and store it in the package level to be able to use it. I won't recommend -also don't like- initializing Container every time it's needed because it makes additional Docker API calls in the initialization time. Please see here.
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.
ok let's keep it like that for now, and for the initialization of the container every time, you're right with the docker api calls even if we could add a singleton on that or some stuff like that but we will think about this kind of optimization later
So this is ok now :)
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 directly changed the corresponding commit from the history as you liked. This way we'll not see an irrelevant code in the init.go file.
var defaultContainer *container.Container | ||
|
||
func init() { | ||
c, err := container.New() |
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.
same remark here, do we really need a state and an init function ?
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, until we refactor service. This is just a temporary solution.
* move integration tests to their own files called with _integration_test.go * add dockertest package to easily test methods that calls Docker API
* add more unit tests to container_test.go, build_test.go, network_test.go * extend dockertest API accordingly
e0e344e
to
f29179a
Compare
* add unit tests to service_test,go, shared_network_test.go, task_test.go, wait_test.go * extend dockertest API accordingly * small fixes
* update container tests accordingly
f29179a
to
c6c680d
Compare
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.
👍 Good to merge 🌮
closes #283.
related with #337, #268.
integration
tag to enable integration tests:go test -tags=integration
dockertest
package provided within this PR is used while unit testing of container package and will be used by its consumer packages to mock Docker API.