Change:
fi kube::log::status "Installing godep version ${GODEP_VERSION}" <del> go install ./vendor/github.com/tools/godep/ </del> <ins> go install k8s.io/kubernetes/vendor/github.com/tools/godep/ </ins> if ! which godep >/dev/null 2>&1; then kube::log::error "Can't find godep - is your GOPATH 'bin' in your PATH?" kube::log::error "  GOPATH: ${GOPATH}"

Discussion:
I am trying to update aws-sdk-go dep version, following the guide in I checkout to the master branch, and I use these commands: But all the "BUILD" files in the "vendor" folder are deleted. What did i do wrongWhat are the right steps? When I use the same commands in the "release-1.9" branch, all these files are not changed.
/sig contributor-experience
I came across this recently as well. same for me. /kind bug
Looks like is the culprit? /cc
you didn't do anything wrong. :) Updating bazel files again will solve the problem for now: But we should either fix the script or update the instructions.
This should run already as a part of godep- Is that step producing any errors?
There are not any error message. Here is the output:
yeah, I can reproduce this - running yields lots of missing files. still investigating, but I'm guessing the files are being generated in the generated gopath (from , rather than the repo root.
... though that shouldn't matter, since it's just a symlink. hm.
I think I found it.. I think it has to do with the fact that the init script uses to strip out symlinks, which doesn't play nice with . I'm testing a fix locally.. if it works, I'll push a PR. I don't know if removing the flag will break other things tho.
Nope. That didn't work. Next test I'm running is a revert of .
after running , if I then run , it still doesn't regenerate the files, which makes me think doesn't like running in the artificial gopath.
oh, I think might full resolve either the or its working directory, which causes problems since we have an artificial gopath. cc if he's seen this before.
seems to need to run from the real (or at least a subdir of the real ). seems to need to run from a valid - i.e. must be in . If I to the real in , works properly, but then explodes.
Just a straight revert of that last change didn't work either. I wonder how long this has been broken for..
When Gazelle starts, it locates the repository root (if is not given, it's the nearest parent directory containing a file named ), then evaluates symlinks in that path.

When Gazelle walks the directory tree, it only follows symlinks to directories that point outside the repository. It checks that by evaluating symlinks, then checking whether the resolved path has the resolved repository root as a prefix. This is all in service of avoiding symlink cycles and preventing the same directory from being visited on more than one path (which would cause incorrect or inconsistent attributes).
I'd guess since .
So I think passing to Gazelle would fix it. Then it won't go looking outside the GOPATH for the WORKSPACE file.
alone doesn't seem to be helping, at least not if I set it to the real repo root. and the files under are still missing. What does seem to help is if I to the real repo root before calling .
note also that it seems that gazelle isn't walking any of the tree when run under ; it's not just that's affected.
Easiest way to reproduce: out kubernetes/kubernetes some file in the tree (e.g. ) that the file you removed wasn't regenerated that the file was now regenerated
yeah, gazelle really doesn't like the symlink. super hacky fix that is probably not a good idea here:
Copying my comment from slack:
Please try again with a fresh master. Fix was merged in last night.
It's ok now!