Fix go.sum

[fsouza]

See golang/go#29278.
Fix #138.

[dhui]

go version go1.11.4 linux/amd64
Builds are failing due to the invalid checksum: https://travis-ci.org/golang-migrate/migrate/jobs/469750108

[dhui]

Not sure if the checksums are failing due to the TravisCI build cache. However, I've cleared my module cache locally and rebuilt migrate and still have the same docker/docker checksum, so the TravisCI build cache is unlikely to be the issue.

[fsouza]

Oh noo, I can't reproduce with a clean setup :(((

$ docker run -v $PWD:/code -w /code -it golang:1.11 make test COVERAGE_DIR=/tmp/coverage

Output here: https://gist.github.com/fsouza/f8fba9869dbd0ee0add12ce1b2897d06

I'll investigate this later today or some time tomorrow. Thanks for the feedback and sorry about the noise!

[fsouza]

@dhui it does look like it may be a caching issue with Travis. I enabled Travis on my fork and go was able to download github.com/docker/docker: https://travis-ci.org/fsouza/migrate/jobs/469813717

An easy "fix" would be to update docker/docker to a newer version and see if the test suite stills passes, this would avoid caching issues that other people may face. We could pin it to the commit right after the current one or we could try to get the latest master and see if everything still works. What do you think?

[coveralls]

Pull Request Test Coverage Report for Build 241

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 57.728%

---

Totals
Change from base Build 240:	0.0%
Covered Lines:	676
Relevant Lines:	1171

---

💛 - Coveralls

[dhui]

Updating docker to a newer released version to get around this issue sounds good. We're due for an update anyways...
It's unclear to me if we need to use docker/docker or docker/engine to pin to a release.

[fsouza]

@dhui yeah unfortunately after moving from docker/docker to moby/moby, the Docker team stopped tagging that repo, so we have to keep picking a commit :(

I pinned it to moby/moby@b6242da. This should be good for review now.

[dhui]

I'd rather avoid picking a commit and use tagged releases. That way, it's clear what version of a dependency we're using.

[fsouza]

There are no tagged releases on docker/docker.

[dhui]

Try docker/engine

[fsouza]

It's not possible to import github.com/docker/engine in the code, so this would require a replace in go.mod (I think):

replace github.com/docker/docker => github.com/docker/engine

I can do it, but it's very ugly :) Let me know what you think.

[dhui]

What are the issues you encountered when importing github.com/docker/engine?
I believe that migrate cannot use the replace directive since the directive is only used by the main module. e.g. migrate is used both as a CLI and a library

[fsouza]

@dhui https://github.com/docker/engine/blob/170ed8d7e732adabe9b452a9a52c7a104ef2b8ec/api/types/container/config.go#L1

[dhui]

@dhui https://github.com/docker/engine/blob/170ed8d7e732adabe9b452a9a52c7a104ef2b8ec/api/types/container/config.go#L1

Oi... Thanks for investigating! In that case, let's stick with the docker/docker import and use commits which correspond to a release tag in docker/engine.
We can start with commit f5749085e9cb0565afe342e73a67631f97547054 which corresponds to tag v18.09.0, but if that has issues, we can use older versions (unless you wanna try to fix any issues that arise)

[fsouza]

Yeah, unfortunately that commit is not in the tree referenced by master on docker/docker :( It's available only on docker/engine's 18.09 branch tree :(

docker/docker@master fails because that's requesting API version 1.40 which isn't released yet, so I pinned to the version that's using API 1.39.

[dhui]

Weird, the docs say that v18.09 supports API v1.30.

Next version to try would be v18.06.1-ce which is commit: 320063a2ad06a1d8ada61c94c29dbe44e2d87473

[fsouza]

Sorry, this strategy isn't gonna work. The tags on docker/engine point to commits that do not exist on docker/docker's tree (though GitHub can render them under docker/docker because docker/engine is a fork).

As an alternative, I tried github.com/docker/docker@master but that didn't work because it's too far ahead, so I dug the commit history and picked the commit for 1.39, and that's what this PR is using.

[dhui]

Sorry, this strategy isn't gonna work. The tags on docker/engine point to commits that do not exist on docker/docker's tree (though GitHub can render them under docker/docker because docker/engine is a fork).

Oh, I thought docker/engine was a normal fork of docker/docker. I didn't realize that the commits were re-written...

As mentioned earlier, I'd rather not pin to arbitrary commit. I'm not familiar enough with the docker package to know which commits are considered stable (e.g. not an alpha/beta/RC release) and don't have a backwards incompatible changes. It'd also be unclear which commit to use for minor bug fixes.

Given the state of the docker/docker package, I think it's better postpone upgrading docker/docker.

I've also figured out the issue I was having with the checksum being being regenerated correctly locally. Earlier, I was using Go 1.11.3 instead of Go 1.11.4... I've now updated to Go 1.11.4 and regenerated go.sum in this commit: 2417646

Thanks again @fsouza for all of the work you've put in to resolving this issue!

[fsouza]

Sounds good. Thanks for the feedback and sorry about the back and forth! :)