-
Notifications
You must be signed in to change notification settings - Fork 814
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
Update vendor of containers/(common,storage,image) #1626
Conversation
Signed-off-by: Daniel J Walsh <[email protected]>
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
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.
I mean, sure — but could we record why is this being done (this way), please?
What makes the three updates simultaneously so important that we want to upgrade (all of them), and so unimportant that they aren’t tagged as upstream releases? All three at the same time?!
@@ -238,7 +238,7 @@ github.com/golang/protobuf/ptypes/timestamp | |||
github.com/google/go-intervals/intervalset | |||
# github.com/google/uuid v1.3.0 | |||
github.com/google/uuid | |||
# github.com/gorilla/mux v1.8.0 | |||
# github.com/gorilla/mux v1.7.4 |
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.
What has happened here?
Trying to reproduce, a go get github.com/containers/[email protected]
adds an
+ github.com/gorilla/mux v1.8.0 // indirect
entry to go.mod
(and several others like that), so no downgrade happens. Was this PR done in some other way that doesn’t protect against downgrades?
Ultimately, AFAICS that doesn’t change the contents of the vendored code, so it doesn’t matter, but I’m worried that next time such a downgrade could make a difference.
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.
These vendors were done the same way every vendor was done.
make vendor-in-container
Nothing special.
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.
vendor-in-container
only updates based on a go.mod
; the initial operation to point at a newer versions must have been done in some other way.
(Unrelated: vendor-in-container
uses quay.io/libpod/golang:1.16
; should that be updated? Podman is using 1.17 at least.)
We are preparing for RC1 release of Podman, and are trying to avoid doing multiple vendor dances. The goal was to get these three in podman, buildah and skopeo and make sure they pass through their CI systems. We will be bumping releases of all three in the next couple of weeks and then releasing new versions of Podman, Buildah and Skopeo. |
Thanks, that’s helpful. |
Signed-off-by: Daniel J Walsh [email protected]