You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current dynamic version selection logic causes failures if you haven't configured an options field in the API call you are making with a big enough 'ver' tag value.
It calls queryStringVersion to figure out the minimal API version based on the provided BuildImageOptions fields. Then it calls pathVersionCheck, which creates buildURL based either on the explicitly configured API version when the client was created or the minimal API version guessed by queryStringVersion.
If you set the Name and ForceRmTmpContainer fields in BuildImageOptionsqueryStringVersion will guess the minimal version to be 1.12 (because the ver tag for the ForceRmTmpContainer field in BuildImageOptions is set to 1.12 ). Then pathVersionCheck will create an API path with 1.12 if you don't create a versioned Client explicitly.
The go-dockerclient claims that if you don't specify an API version then the latest API version will be used, but it's not really the case here.
Thanks for opening this issue and apologies for the delayed response.
I think we can try to adopt the same behavior as the official SDK. Also, I think it's kind of an accident that we don't use the latest version when it's not specified. I'm thinking of trying to fix that, but also understand that that has the potential to break many things. I'll poke around in the next couple of days!
Both sound like a good idea. For the second enhancement how about adding a client option to toggle the behavior to get latest version or to have the original version selection magic? Thank you for the library and no worries about the delays. Pretty sure you have enough on your plate and the open source work is personal time :)
The Docker Engine v25.0 release deprecates the APIs below version 1.24 ( https://docs.docker.com/engine/deprecated/#deprecate-legacy-api-versions ).
The current dynamic version selection logic causes failures if you haven't configured an options field in the API call you are making with a big enough 'ver' tag value.
We can use
(c *Client) BuildImage(opts BuildImageOptions)
as an example: https://github.com/fsouza/go-dockerclient/blob/main/image.go#L537It calls
queryStringVersion
to figure out the minimal API version based on the providedBuildImageOptions
fields. Then it callspathVersionCheck
, which createsbuildURL
based either on the explicitly configured API version when the client was created or the minimal API version guessed byqueryStringVersion
.If you set the
Name
andForceRmTmpContainer
fields inBuildImageOptions
queryStringVersion
will guess the minimal version to be1.12
(because thever
tag for theForceRmTmpContainer
field inBuildImageOptions
is set to1.12
). ThenpathVersionCheck
will create an API path with1.12
if you don't create a versioned Client explicitly.The go-dockerclient claims that if you don't specify an API version then the latest API version will be used, but it's not really the case here.
@fsouza curious what you think about this behavior and how you'd prefer to address it in the library. The docker/moby client has the
NegotiateAPIVersion
call ( https://github.com/moby/moby/blob/v25.0.1/client/client.go#L294 ) that's potentially relevant for this.The text was updated successfully, but these errors were encountered: