@cpuguy83 @AkihiroSuda ptal

failure on amd64 is a known flaky test; #42357

--- FAIL: TestDaemonHostGatewayIP (1.91s)
    daemon_linux_test.go:144: [de50f3b669e81] failed to start daemon with arguments [--data-root /go/src/github.com/docker/docker/bundles/test-integration/TestDaemonHostGatewayIP/de50f3b669e81/root --exec-root /tmp/dxr/de50f3b669e81 --pidfile /go/src/github.com/docker/docker/bundles/test-integration/TestDaemonHostGatewayIP/de50f3b669e81/docker.pid --userland-proxy=true --containerd-namespace de50f3b669e81 --containerd-plugins-namespace de50f3b669e81p --containerd /var/run/docker/containerd/containerd.sock --host unix:///tmp/docker-integration/de50f3b669e81.sock --debug --storage-driver overlay2] : [de50f3b669e81] daemon exited during startup: exit status 1

kicking ci again

This will only work until Go 1.17, right? 😞

This will only work until Go 1.17, right? 😞

Good question; haven't fully caught up on that; will Go 1.17 still support a -mod flag (e.g.) to disable? We can probably work around it in some other way (this was a quick way to get it working and to somewhat unblock #40353)

https://blog.golang.org/go116-module-changes

We plan to drop support for GOPATH mode in Go 1.17. In other words, Go 1.17 will ignore GO111MODULE. If you have projects that do not build in module-aware mode, now is the time to migrate.

(So in short, no, I do not think so -- for Go 1.17 we either have to "convert or die" so to speak.)

So much for "no breaking changes'. Will they still support vendoring? (that's a bit odd as they're not modules either)

Yes! From my testing, even an empty go.mod with -mod vendor does something ~sane, but it's a bit of a hack (and I wouldn't be surprised if they later break it when they notice it's possible, especially if a "big" project like Docker starts using it 🙈).