Change:
The verification tests have been since we enabled them on the release-1.6 branch. It looks like is the failing check. From : Does this check need to be fixed? Should we disable this check on release branches? Or is something actually wrong with the release branch? cc
I don't actually know what this test does. Does this mean is going to fail, or is it just a CI issue? If so that blocks today's beta cut.
cc
Sent
somehow the most recent commit () fixed this. I'm not sure what it did differently vs. the previous times it ran.
I cherrypicked the proposed fix from . It didn't work without that.
I am still getting CI errors during steps for . when I build locally the scripts copies . But when I push the PR, the verification always fails because head does not have that vendored package: and I was hoping would fix, but it is still happening. Any idea?
I don't think client-go depends on , so the verification script is correct. How did you update staging/client-go? Did you do it by running hack/update-staging- Did you rebase your PR to include latest changes on master before you ran the update script?
I was using and that introduced/copied the package. When the update-all- was introduced in HEAD, I got the same result. If I remove the package, my local build fails.
Yes, I have been rebasing consistently trying to get rid of error, but nothing helps so far. If I remove the dependency, my build fail locally and still doesn't pass the CI check.
Just rebased, removed the package, and ran the update script, this is the result:
Does client-go actually depend on ?
please try to find out which of the client-go packages depend on pborman/uuid. You can use something like this:
at some point when the staging build was enabled over the weekend a local build pulled a version of that had a dependency on package. I finally figured out to delete that client-go and got a clean build without that package dependency. Thanks.
where was that faulty client-go? In the GOPATH? Can we do anything to avoid those problems in the future?
it was in the same dir the kubernetes project. Not sure when it got pulled down. I really never used the staging script until earlier this week. So I was not too familiar with its behavior. Once I started to research here in this thread and went back and read the README for staging, I suspected that I probably could just delete the client-go directory. I personally think that client-go and staging should not be inside kubernetes. The script to synchronize it should be in client-go and not in kubernetes. This would remove a bug vector that took me 2.5 days to figure out what's going on. Thanks for your feedback.
With being merged we have removed on possible error of having another client-go in the GOPATH. If I understand you right, you were hit by this. So in master this shouldn't happen anymore. Best regards, Stefan , Vladimir Vivien <:
awesome, good to know. I did noticed this morning when I built, client-go was not placed on the GOPATH anymore. Thanks.

Discussion:
if [ "${FAIL_ON_CHANGES}" = true ]; then echo "running FAIL_ON_CHANGES" <del> ret=0 if diff --ignore-matching-lines='^s*"Comment"' -NauprB -I "GoVersion.*|GodepVersion.*" "${CLIENT_REPO}" "${CLIENT_REPO_TEMP}"; then </del> <ins> # ignore base.go in diff cp "${CLIENT_REPO}/pkg/version/base.go" "${CLIENT_REPO_TEMP}/pkg/version/" if diff -NauprB  -I '^s*"Comment"' -I "GoVersion.*|GodepVersion.*" "${CLIENT_REPO}" "${CLIENT_REPO_TEMP}"; then </ins> echo "${CLIENT_REPO} up to date." cleanup exit 0