2016-09-08 13:11:39 -04:00
|
|
|
package service
|
|
|
|
|
|
|
|
|
|
import (
|
2016-10-13 14:28:32 -04:00
|
|
|
"reflect"
|
2016-09-08 13:11:39 -04:00
|
|
|
"sort"
|
|
|
|
|
"testing"
|
2016-10-13 14:28:32 -04:00
|
|
|
"time"
|
2016-09-08 13:11:39 -04:00
|
|
|
|
2017-10-25 12:59:32 -04:00
|
|
|
"github.com/docker/cli/internal/test/testutil"
|
Update order of '--secret-rm' and '--secret-add'
When using both `--secret-rm` and `--secret-add` on `docker service update`,
`--secret-rm` was always performed last. This made it impossible to update
a secret that was already in use on a service (for example, to change
it's permissions, or mount-location inside the container).
This patch changes the order in which `rm` and `add` are performed,
allowing updating a secret in a single `docker service update`.
Before this change, the `rm` was always performed "last", so the secret
was always removed:
$ echo "foo" | docker secret create foo -f -
foo
$ docker service create --name myservice --secret foo nginx:alpine
62xjcr9sr0c2hvepdzqrn3ssn
$ docker service update --secret-rm foo --secret-add source=foo,target=foo2 myservice
myservice
$ docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Secrets }}' myservice | jq .
null
After this change, the `rm` is performed _first_, allowing users to
update a secret without updating the service _twice_;
$ echo "foo" | docker secret create foo -f -
1bllmvw3a1yaq3eixqw3f7bjl
$ docker service create --name myservice --secret foo nginx:alpine
lr6s3uoggli1x0hab78glpcxo
$ docker service update --secret-rm foo --secret-add source=foo,target=foo2 myservice
myservice
$ docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Secrets }}' myservice | jq .
[
{
"File": {
"Name": "foo2",
"UID": "0",
"GID": "0",
"Mode": 292
},
"SecretID": "tn9qiblgnuuut11eufquw5dev",
"SecretName": "foo"
}
]
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-12-30 12:15:53 -05:00
|
|
|
"github.com/docker/docker/api/types"
|
2016-10-13 14:28:32 -04:00
|
|
|
"github.com/docker/docker/api/types/container"
|
2016-09-08 13:11:39 -04:00
|
|
|
mounttypes "github.com/docker/docker/api/types/mount"
|
|
|
|
|
"github.com/docker/docker/api/types/swarm"
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
"github.com/stretchr/testify/assert"
|
|
|
|
|
"github.com/stretchr/testify/require"
|
Update order of '--secret-rm' and '--secret-add'
When using both `--secret-rm` and `--secret-add` on `docker service update`,
`--secret-rm` was always performed last. This made it impossible to update
a secret that was already in use on a service (for example, to change
it's permissions, or mount-location inside the container).
This patch changes the order in which `rm` and `add` are performed,
allowing updating a secret in a single `docker service update`.
Before this change, the `rm` was always performed "last", so the secret
was always removed:
$ echo "foo" | docker secret create foo -f -
foo
$ docker service create --name myservice --secret foo nginx:alpine
62xjcr9sr0c2hvepdzqrn3ssn
$ docker service update --secret-rm foo --secret-add source=foo,target=foo2 myservice
myservice
$ docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Secrets }}' myservice | jq .
null
After this change, the `rm` is performed _first_, allowing users to
update a secret without updating the service _twice_;
$ echo "foo" | docker secret create foo -f -
1bllmvw3a1yaq3eixqw3f7bjl
$ docker service create --name myservice --secret foo nginx:alpine
lr6s3uoggli1x0hab78glpcxo
$ docker service update --secret-rm foo --secret-add source=foo,target=foo2 myservice
myservice
$ docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Secrets }}' myservice | jq .
[
{
"File": {
"Name": "foo2",
"UID": "0",
"GID": "0",
"Mode": 292
},
"SecretID": "tn9qiblgnuuut11eufquw5dev",
"SecretName": "foo"
}
]
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-12-30 12:15:53 -05:00
|
|
|
"golang.org/x/net/context"
|
2016-09-08 13:11:39 -04:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
func TestUpdateServiceArgs(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("args", "the \"new args\"")
|
|
|
|
|
|
2017-08-07 05:52:40 -04:00
|
|
|
spec := &swarm.ServiceSpec{
|
|
|
|
|
TaskTemplate: swarm.TaskSpec{
|
|
|
|
|
ContainerSpec: &swarm.ContainerSpec{},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
cspec := spec.TaskTemplate.ContainerSpec
|
2016-09-08 13:11:39 -04:00
|
|
|
cspec.Args = []string{"old", "args"}
|
|
|
|
|
|
2017-03-23 20:51:57 -04:00
|
|
|
updateService(nil, nil, flags, spec)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.Equal(t, []string{"the", "new args"}, cspec.Args)
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestUpdateLabels(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("label-add", "toadd=newlabel")
|
|
|
|
|
flags.Set("label-rm", "toremove")
|
|
|
|
|
|
|
|
|
|
labels := map[string]string{
|
|
|
|
|
"toremove": "thelabeltoremove",
|
|
|
|
|
"tokeep": "value",
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
updateLabels(flags, &labels)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.Len(t, labels, 2)
|
|
|
|
|
assert.Equal(t, "value", labels["tokeep"])
|
|
|
|
|
assert.Equal(t, "newlabel", labels["toadd"])
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestUpdateLabelsRemoveALabelThatDoesNotExist(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("label-rm", "dne")
|
|
|
|
|
|
|
|
|
|
labels := map[string]string{"foo": "theoldlabel"}
|
|
|
|
|
updateLabels(flags, &labels)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.Len(t, labels, 1)
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
2017-01-19 18:27:37 -05:00
|
|
|
func TestUpdatePlacementConstraints(t *testing.T) {
|
2016-09-08 13:11:39 -04:00
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("constraint-add", "node=toadd")
|
|
|
|
|
flags.Set("constraint-rm", "node!=toremove")
|
|
|
|
|
|
|
|
|
|
placement := &swarm.Placement{
|
|
|
|
|
Constraints: []string{"node!=toremove", "container=tokeep"},
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-19 18:27:37 -05:00
|
|
|
updatePlacementConstraints(flags, placement)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
require.Len(t, placement.Constraints, 2)
|
|
|
|
|
assert.Equal(t, "container=tokeep", placement.Constraints[0])
|
|
|
|
|
assert.Equal(t, "node=toadd", placement.Constraints[1])
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
2017-01-19 18:27:37 -05:00
|
|
|
func TestUpdatePlacementPrefs(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("placement-pref-add", "spread=node.labels.dc")
|
|
|
|
|
flags.Set("placement-pref-rm", "spread=node.labels.rack")
|
|
|
|
|
|
|
|
|
|
placement := &swarm.Placement{
|
|
|
|
|
Preferences: []swarm.PlacementPreference{
|
|
|
|
|
{
|
|
|
|
|
Spread: &swarm.SpreadOver{
|
|
|
|
|
SpreadDescriptor: "node.labels.rack",
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
Spread: &swarm.SpreadOver{
|
|
|
|
|
SpreadDescriptor: "node.labels.row",
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
updatePlacementPreferences(flags, placement)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
require.Len(t, placement.Preferences, 2)
|
|
|
|
|
assert.Equal(t, "node.labels.row", placement.Preferences[0].Spread.SpreadDescriptor)
|
|
|
|
|
assert.Equal(t, "node.labels.dc", placement.Preferences[1].Spread.SpreadDescriptor)
|
2017-01-19 18:27:37 -05:00
|
|
|
}
|
|
|
|
|
|
2016-09-08 13:11:39 -04:00
|
|
|
func TestUpdateEnvironment(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("env-add", "toadd=newenv")
|
|
|
|
|
flags.Set("env-rm", "toremove")
|
|
|
|
|
|
|
|
|
|
envs := []string{"toremove=theenvtoremove", "tokeep=value"}
|
|
|
|
|
|
|
|
|
|
updateEnvironment(flags, &envs)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
require.Len(t, envs, 2)
|
2016-09-08 13:11:39 -04:00
|
|
|
// Order has been removed in updateEnvironment (map)
|
|
|
|
|
sort.Strings(envs)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.Equal(t, "toadd=newenv", envs[0])
|
|
|
|
|
assert.Equal(t, "tokeep=value", envs[1])
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestUpdateEnvironmentWithDuplicateValues(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("env-add", "foo=newenv")
|
|
|
|
|
flags.Set("env-add", "foo=dupe")
|
|
|
|
|
flags.Set("env-rm", "foo")
|
|
|
|
|
|
|
|
|
|
envs := []string{"foo=value"}
|
|
|
|
|
|
|
|
|
|
updateEnvironment(flags, &envs)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.Len(t, envs, 0)
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestUpdateEnvironmentWithDuplicateKeys(t *testing.T) {
|
|
|
|
|
// Test case for #25404
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("env-add", "A=b")
|
|
|
|
|
|
|
|
|
|
envs := []string{"A=c"}
|
|
|
|
|
|
|
|
|
|
updateEnvironment(flags, &envs)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
require.Len(t, envs, 1)
|
|
|
|
|
assert.Equal(t, "A=b", envs[0])
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestUpdateGroups(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("group-add", "wheel")
|
|
|
|
|
flags.Set("group-add", "docker")
|
|
|
|
|
flags.Set("group-rm", "root")
|
|
|
|
|
flags.Set("group-add", "foo")
|
|
|
|
|
flags.Set("group-rm", "docker")
|
|
|
|
|
|
|
|
|
|
groups := []string{"bar", "root"}
|
|
|
|
|
|
|
|
|
|
updateGroups(flags, &groups)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
require.Len(t, groups, 3)
|
|
|
|
|
assert.Equal(t, "bar", groups[0])
|
|
|
|
|
assert.Equal(t, "foo", groups[1])
|
|
|
|
|
assert.Equal(t, "wheel", groups[2])
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
2016-10-26 23:05:39 -04:00
|
|
|
func TestUpdateDNSConfig(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
|
|
|
|
|
// IPv4, with duplicates
|
|
|
|
|
flags.Set("dns-add", "1.1.1.1")
|
|
|
|
|
flags.Set("dns-add", "1.1.1.1")
|
|
|
|
|
flags.Set("dns-add", "2.2.2.2")
|
|
|
|
|
flags.Set("dns-rm", "3.3.3.3")
|
|
|
|
|
flags.Set("dns-rm", "2.2.2.2")
|
|
|
|
|
// IPv6
|
|
|
|
|
flags.Set("dns-add", "2001:db8:abc8::1")
|
|
|
|
|
// Invalid dns record
|
2017-10-25 12:59:32 -04:00
|
|
|
testutil.ErrorContains(t, flags.Set("dns-add", "x.y.z.w"), "x.y.z.w is not an ip address")
|
2016-10-26 23:05:39 -04:00
|
|
|
|
|
|
|
|
// domains with duplicates
|
|
|
|
|
flags.Set("dns-search-add", "example.com")
|
|
|
|
|
flags.Set("dns-search-add", "example.com")
|
|
|
|
|
flags.Set("dns-search-add", "example.org")
|
|
|
|
|
flags.Set("dns-search-rm", "example.org")
|
|
|
|
|
// Invalid dns search domain
|
2017-10-25 12:59:32 -04:00
|
|
|
testutil.ErrorContains(t, flags.Set("dns-search-add", "example$com"), "example$com is not a valid domain")
|
2016-10-26 23:05:39 -04:00
|
|
|
|
2016-11-08 21:29:10 -05:00
|
|
|
flags.Set("dns-option-add", "ndots:9")
|
|
|
|
|
flags.Set("dns-option-rm", "timeout:3")
|
2016-10-26 23:05:39 -04:00
|
|
|
|
|
|
|
|
config := &swarm.DNSConfig{
|
|
|
|
|
Nameservers: []string{"3.3.3.3", "5.5.5.5"},
|
|
|
|
|
Search: []string{"localdomain"},
|
|
|
|
|
Options: []string{"timeout:3"},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
updateDNSConfig(flags, &config)
|
|
|
|
|
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
require.Len(t, config.Nameservers, 3)
|
|
|
|
|
assert.Equal(t, "1.1.1.1", config.Nameservers[0])
|
|
|
|
|
assert.Equal(t, "2001:db8:abc8::1", config.Nameservers[1])
|
|
|
|
|
assert.Equal(t, "5.5.5.5", config.Nameservers[2])
|
2016-10-26 23:05:39 -04:00
|
|
|
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
require.Len(t, config.Search, 2)
|
|
|
|
|
assert.Equal(t, "example.com", config.Search[0])
|
|
|
|
|
assert.Equal(t, "localdomain", config.Search[1])
|
2016-10-26 23:05:39 -04:00
|
|
|
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
require.Len(t, config.Options, 1)
|
2016-10-26 23:05:39 -04:00
|
|
|
assert.Equal(t, config.Options[0], "ndots:9")
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-08 13:11:39 -04:00
|
|
|
func TestUpdateMounts(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
2016-08-24 04:30:54 -04:00
|
|
|
flags.Set("mount-add", "type=volume,source=vol2,target=/toadd")
|
2016-09-08 13:11:39 -04:00
|
|
|
flags.Set("mount-rm", "/toremove")
|
|
|
|
|
|
|
|
|
|
mounts := []mounttypes.Mount{
|
2016-08-24 04:30:54 -04:00
|
|
|
{Target: "/toremove", Source: "vol1", Type: mounttypes.TypeBind},
|
|
|
|
|
{Target: "/tokeep", Source: "vol3", Type: mounttypes.TypeBind},
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
updateMounts(flags, &mounts)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
require.Len(t, mounts, 2)
|
|
|
|
|
assert.Equal(t, "/toadd", mounts[0].Target)
|
|
|
|
|
assert.Equal(t, "/tokeep", mounts[1].Target)
|
2016-08-24 04:30:54 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestUpdateMountsWithDuplicateMounts(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("mount-add", "type=volume,source=vol4,target=/toadd")
|
|
|
|
|
|
|
|
|
|
mounts := []mounttypes.Mount{
|
|
|
|
|
{Target: "/tokeep1", Source: "vol1", Type: mounttypes.TypeBind},
|
|
|
|
|
{Target: "/toadd", Source: "vol2", Type: mounttypes.TypeBind},
|
|
|
|
|
{Target: "/tokeep2", Source: "vol3", Type: mounttypes.TypeBind},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
updateMounts(flags, &mounts)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
require.Len(t, mounts, 3)
|
|
|
|
|
assert.Equal(t, "/tokeep1", mounts[0].Target)
|
|
|
|
|
assert.Equal(t, "/tokeep2", mounts[1].Target)
|
|
|
|
|
assert.Equal(t, "/toadd", mounts[2].Target)
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestUpdatePorts(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("publish-add", "1000:1000")
|
|
|
|
|
flags.Set("publish-rm", "333/udp")
|
|
|
|
|
|
|
|
|
|
portConfigs := []swarm.PortConfig{
|
|
|
|
|
{TargetPort: 333, Protocol: swarm.PortConfigProtocolUDP},
|
|
|
|
|
{TargetPort: 555},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err := updatePorts(flags, &portConfigs)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
|
|
|
|
require.Len(t, portConfigs, 2)
|
2016-09-08 13:11:39 -04:00
|
|
|
// Do a sort to have the order (might have changed by map)
|
|
|
|
|
targetPorts := []int{int(portConfigs[0].TargetPort), int(portConfigs[1].TargetPort)}
|
|
|
|
|
sort.Ints(targetPorts)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.Equal(t, 555, targetPorts[0])
|
|
|
|
|
assert.Equal(t, 1000, targetPorts[1])
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
2016-12-09 15:17:57 -05:00
|
|
|
func TestUpdatePortsDuplicate(t *testing.T) {
|
2016-09-08 13:11:39 -04:00
|
|
|
// Test case for #25375
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("publish-add", "80:80")
|
|
|
|
|
|
|
|
|
|
portConfigs := []swarm.PortConfig{
|
2016-12-09 15:17:57 -05:00
|
|
|
{
|
|
|
|
|
TargetPort: 80,
|
|
|
|
|
PublishedPort: 80,
|
|
|
|
|
Protocol: swarm.PortConfigProtocolTCP,
|
|
|
|
|
PublishMode: swarm.PortConfigPublishModeIngress,
|
|
|
|
|
},
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err := updatePorts(flags, &portConfigs)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
|
|
|
|
require.Len(t, portConfigs, 1)
|
|
|
|
|
assert.Equal(t, uint32(80), portConfigs[0].TargetPort)
|
2016-09-08 13:11:39 -04:00
|
|
|
}
|
2016-10-13 14:28:32 -04:00
|
|
|
|
|
|
|
|
func TestUpdateHealthcheckTable(t *testing.T) {
|
|
|
|
|
type test struct {
|
|
|
|
|
flags [][2]string
|
|
|
|
|
initial *container.HealthConfig
|
|
|
|
|
expected *container.HealthConfig
|
|
|
|
|
err string
|
|
|
|
|
}
|
|
|
|
|
testCases := []test{
|
|
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"no-healthcheck", "true"}},
|
|
|
|
|
initial: &container.HealthConfig{Test: []string{"CMD-SHELL", "cmd1"}, Retries: 10},
|
|
|
|
|
expected: &container.HealthConfig{Test: []string{"NONE"}},
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"health-cmd", "cmd1"}},
|
|
|
|
|
initial: &container.HealthConfig{Test: []string{"NONE"}},
|
|
|
|
|
expected: &container.HealthConfig{Test: []string{"CMD-SHELL", "cmd1"}},
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"health-retries", "10"}},
|
|
|
|
|
initial: &container.HealthConfig{Test: []string{"NONE"}},
|
|
|
|
|
expected: &container.HealthConfig{Retries: 10},
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"health-retries", "10"}},
|
|
|
|
|
initial: &container.HealthConfig{Test: []string{"CMD", "cmd1"}},
|
|
|
|
|
expected: &container.HealthConfig{Test: []string{"CMD", "cmd1"}, Retries: 10},
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"health-interval", "1m"}},
|
|
|
|
|
initial: &container.HealthConfig{Test: []string{"CMD", "cmd1"}},
|
|
|
|
|
expected: &container.HealthConfig{Test: []string{"CMD", "cmd1"}, Interval: time.Minute},
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"health-cmd", ""}},
|
|
|
|
|
initial: &container.HealthConfig{Test: []string{"CMD", "cmd1"}, Retries: 10},
|
|
|
|
|
expected: &container.HealthConfig{Retries: 10},
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"health-retries", "0"}},
|
|
|
|
|
initial: &container.HealthConfig{Test: []string{"CMD", "cmd1"}, Retries: 10},
|
|
|
|
|
expected: &container.HealthConfig{Test: []string{"CMD", "cmd1"}},
|
|
|
|
|
},
|
2016-11-29 04:58:47 -05:00
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"health-start-period", "1m"}},
|
|
|
|
|
initial: &container.HealthConfig{Test: []string{"CMD", "cmd1"}},
|
|
|
|
|
expected: &container.HealthConfig{Test: []string{"CMD", "cmd1"}, StartPeriod: time.Minute},
|
|
|
|
|
},
|
2016-10-13 14:28:32 -04:00
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"health-cmd", "cmd1"}, {"no-healthcheck", "true"}},
|
|
|
|
|
err: "--no-healthcheck conflicts with --health-* options",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"health-interval", "10m"}, {"no-healthcheck", "true"}},
|
|
|
|
|
err: "--no-healthcheck conflicts with --health-* options",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
flags: [][2]string{{"health-timeout", "1m"}, {"no-healthcheck", "true"}},
|
|
|
|
|
err: "--no-healthcheck conflicts with --health-* options",
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
for i, c := range testCases {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
for _, flag := range c.flags {
|
|
|
|
|
flags.Set(flag[0], flag[1])
|
|
|
|
|
}
|
|
|
|
|
cspec := &swarm.ContainerSpec{
|
|
|
|
|
Healthcheck: c.initial,
|
|
|
|
|
}
|
|
|
|
|
err := updateHealthcheck(flags, cspec)
|
|
|
|
|
if c.err != "" {
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.EqualError(t, err, c.err)
|
2016-10-13 14:28:32 -04:00
|
|
|
} else {
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
2016-10-13 14:28:32 -04:00
|
|
|
if !reflect.DeepEqual(cspec.Healthcheck, c.expected) {
|
|
|
|
|
t.Errorf("incorrect result for test %d, expected health config:\n\t%#v\ngot:\n\t%#v", i, c.expected, cspec.Healthcheck)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-11-03 11:05:00 -04:00
|
|
|
|
|
|
|
|
func TestUpdateHosts(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("host-add", "example.net:2.2.2.2")
|
|
|
|
|
flags.Set("host-add", "ipv6.net:2001:db8:abc8::1")
|
|
|
|
|
// remove with ipv6 should work
|
|
|
|
|
flags.Set("host-rm", "example.net:2001:db8:abc8::1")
|
|
|
|
|
// just hostname should work as well
|
|
|
|
|
flags.Set("host-rm", "example.net")
|
|
|
|
|
// bad format error
|
2017-10-25 12:59:32 -04:00
|
|
|
testutil.ErrorContains(t, flags.Set("host-add", "$example.com$"), `bad format for add-host: "$example.com$"`)
|
2016-11-03 11:05:00 -04:00
|
|
|
|
|
|
|
|
hosts := []string{"1.2.3.4 example.com", "4.3.2.1 example.org", "2001:db8:abc8::1 example.net"}
|
Preserve sort-order of extra hosts, and allow duplicate entries
Extra hosts (`extra_hosts` in compose-file, or `--hosts` in services) adds
custom host/ip mappings to the container's `/etc/hosts`.
The current implementation used a `map[string]string{}` as intermediate
storage, and sorted the results alphabetically when converting to a service-spec.
As a result, duplicate hosts were removed, and order of host/ip mappings was not
preserved (in case the compose-file used a list instead of a map).
According to the **host.conf(5)** man page (http://man7.org/linux/man-pages/man5/host.conf.5.html)
multi Valid values are on and off. If set to on, the resolver
library will return all valid addresses for a host that
appears in the /etc/hosts file, instead of only the first.
This is off by default, as it may cause a substantial
performance loss at sites with large hosts files.
Multiple entries for a host are allowed, and even required for some situations,
for example, to add mappings for IPv4 and IPv6 addreses for a host, as illustrated
by the example hosts file in the **hosts(5)** man page (http://man7.org/linux/man-pages/man5/hosts.5.html):
# The following lines are desirable for IPv4 capable hosts
127.0.0.1 localhost
# 127.0.1.1 is often used for the FQDN of the machine
127.0.1.1 thishost.mydomain.org thishost
192.168.1.10 foo.mydomain.org foo
192.168.1.13 bar.mydomain.org bar
146.82.138.7 master.debian.org master
209.237.226.90 www.opensource.org
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
This patch changes the intermediate storage format to use a `[]string`, and only
sorts entries if the input format in the compose file is a mapping. If the input
format is a list, the original sort-order is preserved.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2017-10-29 20:33:23 -04:00
|
|
|
expected := []string{"1.2.3.4 example.com", "4.3.2.1 example.org", "2001:db8:abc8::1 ipv6.net"}
|
2016-11-03 11:05:00 -04:00
|
|
|
|
Preserve sort-order of extra hosts, and allow duplicate entries
Extra hosts (`extra_hosts` in compose-file, or `--hosts` in services) adds
custom host/ip mappings to the container's `/etc/hosts`.
The current implementation used a `map[string]string{}` as intermediate
storage, and sorted the results alphabetically when converting to a service-spec.
As a result, duplicate hosts were removed, and order of host/ip mappings was not
preserved (in case the compose-file used a list instead of a map).
According to the **host.conf(5)** man page (http://man7.org/linux/man-pages/man5/host.conf.5.html)
multi Valid values are on and off. If set to on, the resolver
library will return all valid addresses for a host that
appears in the /etc/hosts file, instead of only the first.
This is off by default, as it may cause a substantial
performance loss at sites with large hosts files.
Multiple entries for a host are allowed, and even required for some situations,
for example, to add mappings for IPv4 and IPv6 addreses for a host, as illustrated
by the example hosts file in the **hosts(5)** man page (http://man7.org/linux/man-pages/man5/hosts.5.html):
# The following lines are desirable for IPv4 capable hosts
127.0.0.1 localhost
# 127.0.1.1 is often used for the FQDN of the machine
127.0.1.1 thishost.mydomain.org thishost
192.168.1.10 foo.mydomain.org foo
192.168.1.13 bar.mydomain.org bar
146.82.138.7 master.debian.org master
209.237.226.90 www.opensource.org
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
This patch changes the intermediate storage format to use a `[]string`, and only
sorts entries if the input format in the compose file is a mapping. If the input
format is a list, the original sort-order is preserved.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2017-10-29 20:33:23 -04:00
|
|
|
err := updateHosts(flags, &hosts)
|
|
|
|
|
assert.NoError(t, err)
|
|
|
|
|
assert.Equal(t, expected, hosts)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestUpdateHostsPreservesOrder(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("host-add", "foobar:127.0.0.2")
|
|
|
|
|
flags.Set("host-add", "foobar:127.0.0.1")
|
|
|
|
|
flags.Set("host-add", "foobar:127.0.0.3")
|
|
|
|
|
|
|
|
|
|
hosts := []string{}
|
|
|
|
|
err := updateHosts(flags, &hosts)
|
|
|
|
|
assert.NoError(t, err)
|
|
|
|
|
assert.Equal(t, []string{"127.0.0.2 foobar", "127.0.0.1 foobar", "127.0.0.3 foobar"}, hosts)
|
2016-11-03 11:05:00 -04:00
|
|
|
}
|
2016-08-18 21:09:07 -04:00
|
|
|
|
|
|
|
|
func TestUpdatePortsRmWithProtocol(t *testing.T) {
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("publish-add", "8081:81")
|
|
|
|
|
flags.Set("publish-add", "8082:82")
|
|
|
|
|
flags.Set("publish-rm", "80")
|
|
|
|
|
flags.Set("publish-rm", "81/tcp")
|
|
|
|
|
flags.Set("publish-rm", "82/udp")
|
|
|
|
|
|
|
|
|
|
portConfigs := []swarm.PortConfig{
|
2016-12-09 15:17:57 -05:00
|
|
|
{
|
|
|
|
|
TargetPort: 80,
|
|
|
|
|
PublishedPort: 8080,
|
|
|
|
|
Protocol: swarm.PortConfigProtocolTCP,
|
|
|
|
|
PublishMode: swarm.PortConfigPublishModeIngress,
|
|
|
|
|
},
|
2016-08-18 21:09:07 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err := updatePorts(flags, &portConfigs)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
|
|
|
|
require.Len(t, portConfigs, 2)
|
|
|
|
|
assert.Equal(t, uint32(81), portConfigs[0].TargetPort)
|
|
|
|
|
assert.Equal(t, uint32(82), portConfigs[1].TargetPort)
|
2016-08-18 21:09:07 -04:00
|
|
|
}
|
|
|
|
|
|
Update order of '--secret-rm' and '--secret-add'
When using both `--secret-rm` and `--secret-add` on `docker service update`,
`--secret-rm` was always performed last. This made it impossible to update
a secret that was already in use on a service (for example, to change
it's permissions, or mount-location inside the container).
This patch changes the order in which `rm` and `add` are performed,
allowing updating a secret in a single `docker service update`.
Before this change, the `rm` was always performed "last", so the secret
was always removed:
$ echo "foo" | docker secret create foo -f -
foo
$ docker service create --name myservice --secret foo nginx:alpine
62xjcr9sr0c2hvepdzqrn3ssn
$ docker service update --secret-rm foo --secret-add source=foo,target=foo2 myservice
myservice
$ docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Secrets }}' myservice | jq .
null
After this change, the `rm` is performed _first_, allowing users to
update a secret without updating the service _twice_;
$ echo "foo" | docker secret create foo -f -
1bllmvw3a1yaq3eixqw3f7bjl
$ docker service create --name myservice --secret foo nginx:alpine
lr6s3uoggli1x0hab78glpcxo
$ docker service update --secret-rm foo --secret-add source=foo,target=foo2 myservice
myservice
$ docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Secrets }}' myservice | jq .
[
{
"File": {
"Name": "foo2",
"UID": "0",
"GID": "0",
"Mode": 292
},
"SecretID": "tn9qiblgnuuut11eufquw5dev",
"SecretName": "foo"
}
]
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-12-30 12:15:53 -05:00
|
|
|
type secretAPIClientMock struct {
|
|
|
|
|
listResult []swarm.Secret
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s secretAPIClientMock) SecretList(ctx context.Context, options types.SecretListOptions) ([]swarm.Secret, error) {
|
|
|
|
|
return s.listResult, nil
|
|
|
|
|
}
|
|
|
|
|
func (s secretAPIClientMock) SecretCreate(ctx context.Context, secret swarm.SecretSpec) (types.SecretCreateResponse, error) {
|
|
|
|
|
return types.SecretCreateResponse{}, nil
|
|
|
|
|
}
|
|
|
|
|
func (s secretAPIClientMock) SecretRemove(ctx context.Context, id string) error {
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
func (s secretAPIClientMock) SecretInspectWithRaw(ctx context.Context, name string) (swarm.Secret, []byte, error) {
|
|
|
|
|
return swarm.Secret{}, []byte{}, nil
|
|
|
|
|
}
|
2016-11-22 14:03:23 -05:00
|
|
|
func (s secretAPIClientMock) SecretUpdate(ctx context.Context, id string, version swarm.Version, secret swarm.SecretSpec) error {
|
|
|
|
|
return nil
|
|
|
|
|
}
|
Update order of '--secret-rm' and '--secret-add'
When using both `--secret-rm` and `--secret-add` on `docker service update`,
`--secret-rm` was always performed last. This made it impossible to update
a secret that was already in use on a service (for example, to change
it's permissions, or mount-location inside the container).
This patch changes the order in which `rm` and `add` are performed,
allowing updating a secret in a single `docker service update`.
Before this change, the `rm` was always performed "last", so the secret
was always removed:
$ echo "foo" | docker secret create foo -f -
foo
$ docker service create --name myservice --secret foo nginx:alpine
62xjcr9sr0c2hvepdzqrn3ssn
$ docker service update --secret-rm foo --secret-add source=foo,target=foo2 myservice
myservice
$ docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Secrets }}' myservice | jq .
null
After this change, the `rm` is performed _first_, allowing users to
update a secret without updating the service _twice_;
$ echo "foo" | docker secret create foo -f -
1bllmvw3a1yaq3eixqw3f7bjl
$ docker service create --name myservice --secret foo nginx:alpine
lr6s3uoggli1x0hab78glpcxo
$ docker service update --secret-rm foo --secret-add source=foo,target=foo2 myservice
myservice
$ docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Secrets }}' myservice | jq .
[
{
"File": {
"Name": "foo2",
"UID": "0",
"GID": "0",
"Mode": 292
},
"SecretID": "tn9qiblgnuuut11eufquw5dev",
"SecretName": "foo"
}
]
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-12-30 12:15:53 -05:00
|
|
|
|
|
|
|
|
// TestUpdateSecretUpdateInPlace tests the ability to update the "target" of an secret with "docker service update"
|
|
|
|
|
// by combining "--secret-rm" and "--secret-add" for the same secret.
|
|
|
|
|
func TestUpdateSecretUpdateInPlace(t *testing.T) {
|
|
|
|
|
apiClient := secretAPIClientMock{
|
|
|
|
|
listResult: []swarm.Secret{
|
|
|
|
|
{
|
|
|
|
|
ID: "tn9qiblgnuuut11eufquw5dev",
|
|
|
|
|
Spec: swarm.SecretSpec{Annotations: swarm.Annotations{Name: "foo"}},
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("secret-add", "source=foo,target=foo2")
|
|
|
|
|
flags.Set("secret-rm", "foo")
|
|
|
|
|
|
|
|
|
|
secrets := []*swarm.SecretReference{
|
|
|
|
|
{
|
|
|
|
|
File: &swarm.SecretReferenceFileTarget{
|
|
|
|
|
Name: "foo",
|
|
|
|
|
UID: "0",
|
|
|
|
|
GID: "0",
|
|
|
|
|
Mode: 292,
|
|
|
|
|
},
|
|
|
|
|
SecretID: "tn9qiblgnuuut11eufquw5dev",
|
|
|
|
|
SecretName: "foo",
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
updatedSecrets, err := getUpdatedSecrets(apiClient, flags, secrets)
|
|
|
|
|
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.NoError(t, err)
|
|
|
|
|
require.Len(t, updatedSecrets, 1)
|
|
|
|
|
assert.Equal(t, "tn9qiblgnuuut11eufquw5dev", updatedSecrets[0].SecretID)
|
|
|
|
|
assert.Equal(t, "foo", updatedSecrets[0].SecretName)
|
|
|
|
|
assert.Equal(t, "foo2", updatedSecrets[0].File.Name)
|
Update order of '--secret-rm' and '--secret-add'
When using both `--secret-rm` and `--secret-add` on `docker service update`,
`--secret-rm` was always performed last. This made it impossible to update
a secret that was already in use on a service (for example, to change
it's permissions, or mount-location inside the container).
This patch changes the order in which `rm` and `add` are performed,
allowing updating a secret in a single `docker service update`.
Before this change, the `rm` was always performed "last", so the secret
was always removed:
$ echo "foo" | docker secret create foo -f -
foo
$ docker service create --name myservice --secret foo nginx:alpine
62xjcr9sr0c2hvepdzqrn3ssn
$ docker service update --secret-rm foo --secret-add source=foo,target=foo2 myservice
myservice
$ docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Secrets }}' myservice | jq .
null
After this change, the `rm` is performed _first_, allowing users to
update a secret without updating the service _twice_;
$ echo "foo" | docker secret create foo -f -
1bllmvw3a1yaq3eixqw3f7bjl
$ docker service create --name myservice --secret foo nginx:alpine
lr6s3uoggli1x0hab78glpcxo
$ docker service update --secret-rm foo --secret-add source=foo,target=foo2 myservice
myservice
$ docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Secrets }}' myservice | jq .
[
{
"File": {
"Name": "foo2",
"UID": "0",
"GID": "0",
"Mode": 292
},
"SecretID": "tn9qiblgnuuut11eufquw5dev",
"SecretName": "foo"
}
]
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2016-12-30 12:15:53 -05:00
|
|
|
}
|
2017-01-14 03:12:19 -05:00
|
|
|
|
|
|
|
|
func TestUpdateReadOnly(t *testing.T) {
|
2017-08-07 05:52:40 -04:00
|
|
|
spec := &swarm.ServiceSpec{
|
|
|
|
|
TaskTemplate: swarm.TaskSpec{
|
|
|
|
|
ContainerSpec: &swarm.ContainerSpec{},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
cspec := spec.TaskTemplate.ContainerSpec
|
2017-01-14 03:12:19 -05:00
|
|
|
|
|
|
|
|
// Update with --read-only=true, changed to true
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("read-only", "true")
|
2017-03-23 20:51:57 -04:00
|
|
|
updateService(nil, nil, flags, spec)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.True(t, cspec.ReadOnly)
|
2017-01-14 03:12:19 -05:00
|
|
|
|
|
|
|
|
// Update without --read-only, no change
|
|
|
|
|
flags = newUpdateCommand(nil).Flags()
|
2017-03-23 20:51:57 -04:00
|
|
|
updateService(nil, nil, flags, spec)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.True(t, cspec.ReadOnly)
|
2017-01-14 03:12:19 -05:00
|
|
|
|
|
|
|
|
// Update with --read-only=false, changed to false
|
|
|
|
|
flags = newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("read-only", "false")
|
2017-03-23 20:51:57 -04:00
|
|
|
updateService(nil, nil, flags, spec)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.False(t, cspec.ReadOnly)
|
2017-01-14 03:12:19 -05:00
|
|
|
}
|
2017-02-06 00:22:57 -05:00
|
|
|
|
|
|
|
|
func TestUpdateStopSignal(t *testing.T) {
|
2017-08-07 05:52:40 -04:00
|
|
|
spec := &swarm.ServiceSpec{
|
|
|
|
|
TaskTemplate: swarm.TaskSpec{
|
|
|
|
|
ContainerSpec: &swarm.ContainerSpec{},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
cspec := spec.TaskTemplate.ContainerSpec
|
2017-02-06 00:22:57 -05:00
|
|
|
|
|
|
|
|
// Update with --stop-signal=SIGUSR1
|
|
|
|
|
flags := newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("stop-signal", "SIGUSR1")
|
2017-03-23 20:51:57 -04:00
|
|
|
updateService(nil, nil, flags, spec)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.Equal(t, "SIGUSR1", cspec.StopSignal)
|
2017-02-06 00:22:57 -05:00
|
|
|
|
|
|
|
|
// Update without --stop-signal, no change
|
|
|
|
|
flags = newUpdateCommand(nil).Flags()
|
2017-03-23 20:51:57 -04:00
|
|
|
updateService(nil, nil, flags, spec)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.Equal(t, "SIGUSR1", cspec.StopSignal)
|
2017-02-06 00:22:57 -05:00
|
|
|
|
|
|
|
|
// Update with --stop-signal=SIGWINCH
|
|
|
|
|
flags = newUpdateCommand(nil).Flags()
|
|
|
|
|
flags.Set("stop-signal", "SIGWINCH")
|
2017-03-23 20:51:57 -04:00
|
|
|
updateService(nil, nil, flags, spec)
|
Remove pkg/testutil/assert in favor of testify
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-04-13 18:45:37 -04:00
|
|
|
assert.Equal(t, "SIGWINCH", cspec.StopSignal)
|
2017-02-06 00:22:57 -05:00
|
|
|
}
|
