Migrate volumes tests in integration-cli to api tests#36292
Conversation
There was a problem hiding this comment.
There are actually two formats. One is source:target which is added to c.HostConfig.Binds. Another is path (without :) which is added to c.Config.Volumes. Maybe one WithBind() and another one WithVolume()?
There was a problem hiding this comment.
WithBind(src, target string) WithVolume(name string) SGTM
fe70d54 to
3efbed4
Compare
|
Thanks @vdemeester @dnephin for the review. The PR has been updated. Please take a look. |
There was a problem hiding this comment.
Checking the list contains a specific name is a pretty weak assertion.
Can we use a label and filter so that we can use assert.Equal() ?
Can we compare the entire struct instead of just names?
There was a problem hiding this comment.
Thanks @dnephin. I updated the PR so that now all elements (except for create time) is compared against.
There was a problem hiding this comment.
Does this need to create a container? Could we use the volume create API instead? It should be much faster and lets us test the volume system independently from containers.
There was a problem hiding this comment.
Thanks @dnephin. I think it make sense to not create the container. I updated the PR. Also I merged TestVolumesCreate and TestVolumesList into TestVolumesCreateAndList.
There was a problem hiding this comment.
I still see it creating a conatiner here. Is that change not pushed?
There was a problem hiding this comment.
Looks like it's needed to get a "volume in use" error below
Likely the container doesn't have to be started though, only created (which would make the test faster to run and cleanup)
There was a problem hiding this comment.
@thaJeztah @dnephin Thanks. The PR has been updated. Now the container is created but not started.
There was a problem hiding this comment.
Could this assert.Equal() the entire struct instead of just the mountpoint?
There was a problem hiding this comment.
Done. It is now compared against the whole Volume struct.
There was a problem hiding this comment.
In this case I guess the container is necessary to test the "in use" case. It would be great if this could be done with a unit test instead, because it would be easier to set up that state without involving the container subsystem.
I guess it's ok like this.
There was a problem hiding this comment.
https://godoc.org/github.com/gotestyourself/gotestyourself/assert/cmp#DeepEqual should make this type of comparison a lot cleaner. I hope we can use it soon.
There was a problem hiding this comment.
@dnephin Thanks. It seems that a vendor update is needed. I will take a look and create a follow up PR for that.
There was a problem hiding this comment.
Don't worry about using it just yet. I have an automated migration that we can use to convert things all at once. I'll open a PR for it soon.
3efbed4 to
489fe2f
Compare
|
@dnephin Thanks for the review. The PR has been updated. I will create a follow up PR to try to utilize |
|
@yongtang hum, janky failed |
19b79bf to
2559ad9
Compare
|
Think there might be some leftover from previous tests. I added additional logging to take a look. |
edd0ae8 to
bb4efdb
Compare
|
The build failure is caused by additional volume |
|
Opened a PR docker/docker-py#1909 in docker-py to remove |
This fix updates docker-py: ``` -ENV DOCKER_PY_COMMIT 1d6b5b203222ba5df7dedfcd1ee061a452f99c8a +ENV DOCKER_PY_COMMIT 5e28dcaace5f7b70cbe44c313b7a3b288fa38916 ``` The updated docker-py includes docker/docker-py#1909 which is required to have moby#36292 pass the tests. Full diff is in docker/docker-py@1d6b5b2...5e28dca. Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
|
docker/docker-py#1909 has been merged. Created a PR #36318 to update the docker-py. |
bfc676f to
2f33c0c
Compare
Codecov Report
@@ Coverage Diff @@
## master #36292 +/- ##
=========================================
Coverage ? 34.64%
=========================================
Files ? 612
Lines ? 45297
Branches ? 0
=========================================
Hits ? 15695
Misses ? 27544
Partials ? 2058 |
|
Looks like there's some failures; Once addressed, can you also squash commits? I think it's clearer if the test "remove" and "move" are in a single commit |
|
@thaJeztah Thanks. I am still trying to figure out where the volumes comes from. Might be from docker-py but I am not so sure. May still need to play with the Jenkins build around. Will squash once I figure it out. |
9f0ee2f to
056156a
Compare
|
Added a PR in docker-py docker/docker-py#1922 |
056156a to
af955d1
Compare
|
@thaJeztah The PR has been updated. Please take a look. |
There was a problem hiding this comment.
Doc doesn't match the function? 😅
There was a problem hiding this comment.
I know this was discussed in some other PR's; should this be a unique name (to allow tests running in parallel?). Could use t.Name() as part of the volume-name to make it unique, or just a random name
There was a problem hiding this comment.
Same here with the name. In this case, I don't think we need a name at all (as we can reference the container by it's ID, correct?)
af955d1 to
be78e25
Compare
|
Thanks @thaJeztah for the review. The PR has been updated. |
This fix migrates volumes tests in integration-cli to api tests in integration/ Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
be78e25 to
d896f87
Compare
This fix migrates volumes tests in integration-cli to api tests in integration/
Signed-off-by: Yong Tang yong.tang.github@outlook.com