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
|
|
|
|
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
|
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, 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
|
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, 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
|
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, 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"}
|
|
|
|
|
|
|
|
|
|
updateHosts(flags, &hosts)
|
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, hosts, 3)
|
|
|
|
|
assert.Equal(t, "1.2.3.4 example.com", hosts[0])
|
|
|
|
|
assert.Equal(t, "2001:db8:abc8::1 ipv6.net", hosts[1])
|
|
|
|
|
assert.Equal(t, "4.3.2.1 example.org", hosts[2])
|
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
|
|
|
}
|
