-
Notifications
You must be signed in to change notification settings - Fork 886
Dockerfile: Install a fixed version of gogoprotobuf #2242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This avoids build failures when gogoprotobuf is changed upstream. Signed-off-by: Euan Harris <euan.harris@docker.com>
|
It looks like they have just made a release, so we should consider jumping to v1.1.1 and regenerating in another pull request. Unfortunately this will be more work than just bumping the tag, as we get build failures with the newest version: |
|
o fix the undefined message you have to bump the version of protobuf in the vendor from 1.0.0 to 1.1.1 The next problem looks like that the structure PortConfig is not anymore a valid key for a map: |
|
@fcrisciani Yes, I don't want to get up to the latest version in this PR - this is just to pin the version of the tools we use so that @selansen can get #2241 to build. Without this change, any PR to master will now fail in the |
fcrisciani
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This results in a XXX_unrecognized of type []byte to be created in the struct. As a side effect the struct can't be used as a map key anymore, resulting in a libnetwork build failure. Fix this by setting goproto_unrecognized_all=false which suppresses this field. Upstream doesn't have the problem because they have pinned an older version of gogo/protobuf: moby/libnetwork#2242 Author: Felix Geyer <fgeyer@debian.org> Gbp-Pq: Name libnetwork_proto_no_unrecognized_all.patch
Gogoprotobuf has changed upstream and now generates different output. Check out a specific commit to avoid this.
We may be able to do something like this with
go getin 1.11 with 'module aware mode':