-
Notifications
You must be signed in to change notification settings - Fork 70
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
Rev k8s to 1.29.4 #562
Rev k8s to 1.29.4 #562
Conversation
Makefile
Outdated
@@ -105,6 +105,7 @@ push: image | |||
docker push $(GOBUILD_ARCH_IMAGE) | |||
# to handle default case, because quay.io does not support manifest yet | |||
ifeq ($(ARCH),amd64) | |||
docker tag $(GOBUILD_ARCH_IMAGE) $(GOBUILD_IMAGE) |
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.
Why do you need this change?
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.
This may not be the ideal fix for the failure, so Im open to suggestions, but:
A CI run is failing with error:
docker: Error response from daemon: manifest for calico/go-build:rev-k8s-to-1-29-4 not found: manifest unknown: manifest unknown.
So, this was a short attempt to fix that, though the change did not appear to get used in the CI following this commit 🤔
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.
It needs to be a multi-arch manifest; not necessarily a retagged amd46 image. For your work in projectcalico/calico#8805, you probably can get away with updating go-build. The current version (v0.91) should be good to use. I believe the k8s libs/binaries in the build container is mostly for UT/FVs.
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.
That's fair enough, but what do you suggest is the fix then, for the missing image in the CI? Or maybe a better question is why is it failing? 😄
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 believe the k8s libs/binaries in the build container is mostly for UT/FVs.
That sounds plausible, but Im seeing quite a few failures in the tests as a result of revving the libs. Should this be cause for concern? Im currently in the process of deploying a real test cluster with Calico pinned to k8s1.29 to see if the issues arise outside of just the tests
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.
for the missing image in the CI
You mean the projectcalico/calico CI failure or this go-build CI failure? For calico, I used to push images+multi-arch manifest to my own dockerhub account and use that. For the go-build CI, I am unable to fetch semaphore logs for this build.
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.
The latest CI run appears to be bugged - will push another commit and hopefully thats visible
56ba185
to
a2a244d
Compare
a2a244d
to
51b4948
Compare
No description provided.