Add Dockerfile and fix vendor.conf #1

dnephin · 2017-04-18T21:36:01Z

These two repos are not used

Signed-off-by: Daniel Nephin <[email protected]>

gdevillele · 2017-04-21T16:31:40Z

LGTM 🐝

vdemeester

LGTM 🐯 but I have a small question about the vendor.conf content 👼

vdemeester · 2017-04-21T17:11:28Z

vendor.conf

 github.com/docker/swarmkit b19d028de0a6e9ca281afeb76cea2544b9edd839
 github.com/flynn-archive/go-shlex 3f9db97f856818214da2e1057f8ad84803971cff
-github.com/golang/protobuf 8ee79997227bf9b34611aee7946ae64735e6fd93
+github.com/go-check/check 4ed411733c5785b40214c70bce814c3a3a689609 https://github.com/cpuguy83/check.git


Is this still required ? we don't use check in the cli tests right ?
Same goes for a few others (protobuf, etc..)

For now it is required. There is an import from docker/docker/pkg/testutil/cmd because some people insisted that I support the matcher interface, which required that import.

pkg/testutil/ imports pkg/testutil/cmd and this repo uses pkg/testutil.

We can definitely fix this in two ways.

remove the matcher from pkg/testutil/cmd, I don't think it's actually used much, we mostly do result.Assert() everywhere. Or we could move the matcher to another package.

split pkg/testutil/ so that it doesn't have things for both integration testing and unit testing.

I think we should do both.

I haven't traced the other imports. I suspect it will be something similar where a util package is being used for too many different things.

I do agree on both 👼 👍

Implemented docker stack logs (swarm + kube)

This makes a quick pass through our tests; Discard output/err ---------------------------------------------- Many tests were testing for error-conditions, but didn't discard output. This produced a lot of noise when running the tests, and made it hard to discover if there were actual failures, or if the output was expected. For example: === RUN TestConfigCreateErrors Error: "create" requires exactly 2 arguments. See 'create --help'. Usage: create [OPTIONS] CONFIG file|- [flags] Create a config from a file or STDIN Error: "create" requires exactly 2 arguments. See 'create --help'. Usage: create [OPTIONS] CONFIG file|- [flags] Create a config from a file or STDIN Error: error creating config --- PASS: TestConfigCreateErrors (0.00s) And after discarding output: === RUN TestConfigCreateErrors --- PASS: TestConfigCreateErrors (0.00s) Use sub-tests where possible ---------------------------------------------- Some tests were already set-up to use test-tables, and even had a usable name (or in some cases "error" to check for). Change them to actual sub- tests. Same test as above, but now with sub-tests and output discarded: === RUN TestConfigCreateErrors === RUN TestConfigCreateErrors/requires_exactly_2_arguments === RUN TestConfigCreateErrors/requires_exactly_2_arguments#01 === RUN TestConfigCreateErrors/error_creating_config --- PASS: TestConfigCreateErrors (0.00s) --- PASS: TestConfigCreateErrors/requires_exactly_2_arguments (0.00s) --- PASS: TestConfigCreateErrors/requires_exactly_2_arguments#01 (0.00s) --- PASS: TestConfigCreateErrors/error_creating_config (0.00s) PASS It's not perfect in all cases (in the above, there's duplicate "expected" errors, but Go conveniently adds "#1" for the duplicate). There's probably also various tests I missed that could still use the same changes applied; we can improve these in follow-ups. Set cmd.Args to prevent test-failures ---------------------------------------------- When running tests from my IDE, it compiles the tests before running, then executes the compiled binary to run the tests. Cobra doesn't like that, because in that situation `os.Args` is taken as argument for the command that's executed. The command that's tested now sees the test- flags as arguments (`-test.v -test.run ..`), which causes various tests to fail ("Command XYZ does not accept arguments"). # compile the tests: go test -c -o foo.test # execute the test: ./foo.test -test.v -test.run TestFoo === RUN TestFoo Error: "foo" accepts no arguments. The Cobra maintainers ran into the same situation, and for their own use have added a special case to ignore `os.Args` in these cases; https://github.com/spf13/cobra/blob/v1.8.1/command.go#L1078-L1083 args := c.args // Workaround FAIL with "go test -v" or "cobra.test -test.v", see #155 if c.args == nil && filepath.Base(os.Args[0]) != "cobra.test" { args = os.Args[1:] } Unfortunately, that exception is too specific (only checks for `cobra.test`), so doesn't automatically fix the issue for other test-binaries. They did provide a `cmd.SetArgs()` utility for this purpose https://github.com/spf13/cobra/blob/v1.8.1/command.go#L276-L280 // SetArgs sets arguments for the command. It is set to os.Args[1:] by default, if desired, can be overridden // particularly useful when testing. func (c *Command) SetArgs(a []string) { c.args = a } And the fix is to explicitly set the command's args to an empty slice to prevent Cobra from falling back to using `os.Args[1:]` as arguments. cmd := newSomeThingCommand() cmd.SetArgs([]string{}) Some tests already take this issue into account, and I updated some tests for this, but there's likely many other ones that can use the same treatment. Perhaps the Cobra maintainers would accept a contribution to make their condition less specific and to look for binaries ending with a `.test` suffix (which is what compiled binaries usually are named as). Signed-off-by: Sebastiaan van Stijn <[email protected]>

This makes a quick pass through our tests; Discard output/err ---------------------------------------------- Many tests were testing for error-conditions, but didn't discard output. This produced a lot of noise when running the tests, and made it hard to discover if there were actual failures, or if the output was expected. For example: === RUN TestConfigCreateErrors Error: "create" requires exactly 2 arguments. See 'create --help'. Usage: create [OPTIONS] CONFIG file|- [flags] Create a config from a file or STDIN Error: "create" requires exactly 2 arguments. See 'create --help'. Usage: create [OPTIONS] CONFIG file|- [flags] Create a config from a file or STDIN Error: error creating config --- PASS: TestConfigCreateErrors (0.00s) And after discarding output: === RUN TestConfigCreateErrors --- PASS: TestConfigCreateErrors (0.00s) Use sub-tests where possible ---------------------------------------------- Some tests were already set-up to use test-tables, and even had a usable name (or in some cases "error" to check for). Change them to actual sub- tests. Same test as above, but now with sub-tests and output discarded: === RUN TestConfigCreateErrors === RUN TestConfigCreateErrors/requires_exactly_2_arguments === RUN TestConfigCreateErrors/requires_exactly_2_arguments#01 === RUN TestConfigCreateErrors/error_creating_config --- PASS: TestConfigCreateErrors (0.00s) --- PASS: TestConfigCreateErrors/requires_exactly_2_arguments (0.00s) --- PASS: TestConfigCreateErrors/requires_exactly_2_arguments#01 (0.00s) --- PASS: TestConfigCreateErrors/error_creating_config (0.00s) PASS It's not perfect in all cases (in the above, there's duplicate "expected" errors, but Go conveniently adds "#1" for the duplicate). There's probably also various tests I missed that could still use the same changes applied; we can improve these in follow-ups. Set cmd.Args to prevent test-failures ---------------------------------------------- When running tests from my IDE, it compiles the tests before running, then executes the compiled binary to run the tests. Cobra doesn't like that, because in that situation `os.Args` is taken as argument for the command that's executed. The command that's tested now sees the test- flags as arguments (`-test.v -test.run ..`), which causes various tests to fail ("Command XYZ does not accept arguments"). # compile the tests: go test -c -o foo.test # execute the test: ./foo.test -test.v -test.run TestFoo === RUN TestFoo Error: "foo" accepts no arguments. The Cobra maintainers ran into the same situation, and for their own use have added a special case to ignore `os.Args` in these cases; https://github.com/spf13/cobra/blob/v1.8.1/command.go#L1078-L1083 args := c.args // Workaround FAIL with "go test -v" or "cobra.test -test.v", see #155 if c.args == nil && filepath.Base(os.Args[0]) != "cobra.test" { args = os.Args[1:] } Unfortunately, that exception is too specific (only checks for `cobra.test`), so doesn't automatically fix the issue for other test-binaries. They did provide a `cmd.SetArgs()` utility for this purpose https://github.com/spf13/cobra/blob/v1.8.1/command.go#L276-L280 // SetArgs sets arguments for the command. It is set to os.Args[1:] by default, if desired, can be overridden // particularly useful when testing. func (c *Command) SetArgs(a []string) { c.args = a } And the fix is to explicitly set the command's args to an empty slice to prevent Cobra from falling back to using `os.Args[1:]` as arguments. cmd := newSomeThingCommand() cmd.SetArgs([]string{}) Some tests already take this issue into account, and I updated some tests for this, but there's likely many other ones that can use the same treatment. Perhaps the Cobra maintainers would accept a contribution to make their condition less specific and to look for binaries ending with a `.test` suffix (which is what compiled binaries usually are named as). Signed-off-by: Sebastiaan van Stijn <[email protected]> (cherry picked from commit ab23024) Signed-off-by: Sebastiaan van Stijn <[email protected]>

contains a fix for CVE-2024-45338 / https://go.dev/issue/70906, but it doesn't affect our codebase: govulncheck -show=verbose ./... Scanning your code and 1260 packages across 211 dependent modules for known vulnerabilities... ... Vulnerability #1: GO-2024-3333 Non-linear parsing of case-insensitive content in golang.org/x/net/html More info: https://pkg.go.dev/vuln/GO-2024-3333 Module: golang.org/x/net Found in: golang.org/x/[email protected] Fixed in: golang.org/x/[email protected] Your code is affected by 0 vulnerabilities. This scan also found 0 vulnerabilities in packages you import and 1 vulnerability in modules you require, but your code doesn't appear to call these vulnerabilities. full diff: golang/net@v0.32.0...v0.33.0 Signed-off-by: Sebastiaan van Stijn <[email protected]>

prevent image prune panic

Update vendor.conf

31c8672

Signed-off-by: Daniel Nephin <[email protected]>

dnephin force-pushed the add-dockerfile branch from fbbd7a9 to b6cba06 Compare April 18, 2017 23:12

Add a Dockerfile for building and testing.

b6cba06

Signed-off-by: Daniel Nephin <[email protected]>

dnephin changed the title ~~Update vendor.conf~~ Add Dockerfile and fix vendor.conf Apr 18, 2017

vdemeester approved these changes Apr 21, 2017

View reviewed changes

dnephin merged commit bbee80a into docker:master Apr 21, 2017

dnephin deleted the add-dockerfile branch April 21, 2017 17:19

gdevillele mentioned this pull request Apr 21, 2017

add Makefile #3

Merged

thaJeztah added this to the 17.06.0 milestone Jul 21, 2017

vdemeester pushed a commit to vdemeester/docker-cli that referenced this pull request Oct 13, 2017

Merge pull request docker#1 from simonferquel/stack-logs

a74af0e

Implemented docker stack logs (swarm + kube)

rkgade mentioned this pull request Jan 20, 2018

make -f docker.Makefile binary : failed from 17.11 onwards #823

Closed

diablodale mentioned this pull request Feb 10, 2020

[18.09] Fix compose parser fails 3.4+ schema for volume #2317

Open

friesje306 mentioned this pull request Jan 5, 2021

Using a non-root user who is NOT member of the docker group I get a panic using docker info --format '{{.Swarm.LocalNodeState}}' #2910

Closed

0xswitch mentioned this pull request Jan 9, 2021

containers in bridge network can't access internet (no route to host) #2925

Closed

huhouhua mentioned this pull request Jul 3, 2024

fatal: morestack on g0 #5217

Closed

thaJeztah mentioned this pull request Jul 3, 2024

test spring-cleaning #5224

Merged

thaJeztah mentioned this pull request Jul 19, 2024

[27.1] test spring-cleaning #5270

Merged

nobiit pushed a commit to nobidev/docker-cli that referenced this pull request Nov 19, 2025

Merge pull request docker#1 from mlaventure/chp-moby-33409

8d44c9a

prevent image prune panic

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add Dockerfile and fix vendor.conf #1

Add Dockerfile and fix vendor.conf #1

Uh oh!

dnephin commented Apr 18, 2017

Uh oh!

gdevillele commented Apr 21, 2017

Uh oh!

vdemeester left a comment

Uh oh!

vdemeester Apr 21, 2017

Uh oh!

dnephin Apr 21, 2017 •

edited

Loading

Uh oh!

dnephin Apr 21, 2017

Uh oh!

vdemeester Apr 21, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Add Dockerfile and fix vendor.conf #1

Add Dockerfile and fix vendor.conf #1

Uh oh!

Conversation

dnephin commented Apr 18, 2017

Uh oh!

gdevillele commented Apr 21, 2017

Uh oh!

vdemeester left a comment

Choose a reason for hiding this comment

Uh oh!

vdemeester Apr 21, 2017

Choose a reason for hiding this comment

Uh oh!

dnephin Apr 21, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dnephin Apr 21, 2017

Choose a reason for hiding this comment

Uh oh!

vdemeester Apr 21, 2017

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dnephin Apr 21, 2017 •

edited

Loading