vendor: github.com/docker/docker master (v29.0-dev)#6193
vendor: github.com/docker/docker master (v29.0-dev)#6193thaJeztah merged 1 commit intodocker:masterfrom
Conversation
Codecov ReportAttention: Patch coverage is
📢 Thoughts on this report? Let us know! |
thaJeztah
force-pushed
the
bump_engine
branch
4 times, most recently
from
876cade to
426ae98
Compare
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
|
@vvoland ptal 🤗 |
| @@ -6,6 +6,12 @@ module github.com/docker/cli | |||
|
|
|||
| go 1.23.0 | |||
|
|
|||
| replace ( | |||
| // FIXME(thaJeztah): temporarily need to pin on commits, otherwise go modules won't resolve until these are tagged. | |||
| github.com/moby/moby/api => github.com/moby/moby/api v0.0.0-20250721205005-81caabae43aa | |||
There was a problem hiding this comment.
Don't want to just put these in the require for now rather than use replace?
There was a problem hiding this comment.
That didn't want to work, because api/ and client/ don't have existing tags, so go modules then generates an invalid pseudo version and barfs out
There was a problem hiding this comment.
I can give it another try to see what the exact error was; there's some more PRs merged in moby that I can bump as well; otherwise we'll just have to keep the replace for now
There was a problem hiding this comment.
Can still get this in, but would be curious about the error with pseudo versioning. Personally, I really don't like the pseudo versioning and would rather just create alpha/beta tags. For pseudo versioning I always have to try it, fail, then copy in the pseudo version from the error.
There was a problem hiding this comment.
Yeah, Go should never have done the pseudo-versions; just considered "if you specify a commit, we won't do any version resolution; it's your responsibility now").
This is the error I get; problem looks to be that it wants to generate a pseudo version, but can't do so, because there's no pre-existing api/vx.y.z or client/vx.y.z tag - I suspect this is all because it want's to dream up a version. Honestly I think it's a bug in Go (for v0.0.0 case)
3.472 go 1.23.0
3.472 + trap 'rm -f "${ROOTDIR}/go.mod"' EXIT
3.472 + GO111MODULE=on
3.472 + GOTOOLCHAIN=local
3.472 + ./scripts/vendor update
3.473 + go mod tidy -modfile=vendor.mod
5.318 go: github.com/moby/moby/api@v0.0.0: reading github.com/moby/moby/api/go.mod at revision api/v0.0.0: unknown revision api/v0.0.0
5.321 + rm -f /src/go.mod
Trying to trick it into using the same version as docker/docker also doesn't work, because it has a go.mod so +incompatible is no longer allowed;
17.95 github.com/kylelemons/godebug/diff: github.com/moby/moby/api@v28.2.3-0.20250721205005-81caabae43aa+incompatible: invalid version: module contains a go.mod file, so module path must match major version ("github.com/moby/moby/api/v28")
So I tried to trick it with the last "SemVer" tag in moby/moby master, which was v1.13.1, so using v1.13.2 pseudo-version, but nope, it still wants a api/vxxx tag;
18.21 github.com/kylelemons/godebug/diff: github.com/moby/moby/api@v1.13.2-0.20250721205005-81caabae43aa: invalid pseudo-version: preceding tag (v1.13.1) not found
|
Let me bring this one in; more coming after this |
6 participants
- What I did
- How I did it
- How to verify it
- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)