kubernetes: hack/update-bazel.sh fails with several complaints about "too few values in struct initializer"

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind feature

What happened:

$ ./hack/update-bazel.sh 
Cloning into '/tmp/tmp.TJKUY3llxw/go/src/github.com/kubernetes/repo-infra'...
remote: Counting objects: 848, done.
remote: Total 848 (delta 0), reused 0 (delta 0), pack-reused 848
Receiving objects: 100% (848/848), 261.63 KiB | 6.38 MiB/s, done.
Resolving deltas: 100% (385/385), done.
Cloning into '/tmp/tmp.TJKUY3llxw/go/src/github.com/bazelbuild/rules_go'...
remote: Counting objects: 9243, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 9243 (delta 0), reused 0 (delta 0), pack-reused 9237
Receiving objects: 100% (9243/9243), 2.08 MiB | 8.25 MiB/s, done.
Resolving deltas: 100% (5975/5975), done.
# github.com/bazelbuild/rules_go/go/tools/gazelle/merger
go/tools/gazelle/merger/fix.go:93:28: too few values in struct initializer
go/tools/gazelle/merger/merger.go:498:19: too few values in struct initializer
go/tools/gazelle/merger/merger.go:502:19: too few values in struct initializer
# github.com/bazelbuild/rules_go/go/tools/gazelle/rules
go/tools/gazelle/rules/generator.go:196:16: too few values in struct initializer
go/tools/gazelle/rules/sort_labels.go:30:16: too few values in struct initializer
!!! [0226 14:06:43] Call tree:
!!! [0226 14:06:43]  1: ./hack/update-bazel.sh:34 kube::util::go_install_from_commit(...)
!!! Error in /home/mspreitz/go/src/k8s.io/kubernetes/hack/lib/util.sh:487
  Error in /home/mspreitz/go/src/k8s.io/kubernetes/hack/lib/util.sh:487. '((i<3-1))' exited with status 2
Call stack:
  1: /home/mspreitz/go/src/k8s.io/kubernetes/hack/lib/util.sh:487 kube::util::go_install_from_commit(...)
  2: ./hack/update-bazel.sh:34 main(...)
Exiting with status 1
!!! [0226 14:06:43] Call tree:
!!! [0226 14:06:43]  1: ./hack/update-bazel.sh:34 kube::util::go_install_from_commit(...)
!!! Error in /home/mspreitz/go/src/k8s.io/kubernetes/hack/lib/util.sh:472
  Error in /home/mspreitz/go/src/k8s.io/kubernetes/hack/lib/util.sh:472. '((i<3-1))' exited with status 1
Call stack:
  1: /home/mspreitz/go/src/k8s.io/kubernetes/hack/lib/util.sh:472 kube::util::go_install_from_commit(...)
  2: ./hack/update-bazel.sh:34 main(...)
Exiting with status 1

What you expected to happen: I expected the update to run successfully.

How to reproduce it (as minimally and precisely as possible): Checkout. build/run.sh make. hack/update-bazel.sh

Anything else we need to know?: I get this in both master and release-1.9. I tested most carefully in release-1.9 (because I am working on a cherry-pick right now). In particular, I blew away the container and image I had used earlier for building. Before running hack/update-bazel.sh I established this state:

mspreitz@ubu17dev:~/go/src/k8s.io/kubernetes$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello-world         latest              f2a91732366c        3 months ago        1.85kB
mspreitz@ubu17dev:~/go/src/k8s.io/kubernetes$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
mspreitz@ubu17dev:~/go/src/k8s.io/kubernetes$ 

Then I ran build/run.sh make — which took a while but eventually completed. It left me this state:

mspreitz@ubu17dev:~/go/src/k8s.io/kubernetes$ docker ps -a
CONTAINER ID        IMAGE                                    COMMAND                  CREATED             STATUS                      PORTS               NAMES
dae3627e1150        kube-build:build-da2f51b002-5-v1.9.2-1   "chown -R 1000:1000 …"   20 minutes ago      Exited (0) 17 minutes ago                       kube-build-data-da2f51b002-5-v1.9.2-1
mspreitz@ubu17dev:~/go/src/k8s.io/kubernetes$ docker images
REPOSITORY                            TAG                           IMAGE ID            CREATED             SIZE
kube-build                            build-da2f51b002-5-v1.9.2-1   b90e5435889f        20 minutes ago      2.18GB
hello-world                           latest                        f2a91732366c        3 months ago        1.85kB
gcr.io/google_containers/kube-cross   v1.9.2-1                      ba98259b52f7        3 months ago        1.74GB

After that is when I ran the hack/update-bazel.sh that is exhibited at the start of this issue.

Environment:

  • Kubernetes version (use kubectl version): Commit 77487e4d2e8ebfddd2539544d806f3a17ea61834 (current release-1.9)
  • Cloud provider or hardware configuration: local VM
  • OS (e.g. from /etc/os-release): Ubuntu 17.10
  • Kernel (e.g. uname -a): Linux ubu17dev 4.13.0-21-generic #24-Ubuntu SMP Mon Dec 18 17:29:16 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
  • Install tools:
  • Others: Docker 17.12.0-ce

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 17 (17 by maintainers)

Commits related to this issue

Most upvoted comments

@liggitt 1.7 is unaffected because it doesn’t use gazelle. I just opened #60523 with the same hacky fix for 1.8.

apologies for all these breakages. my technical debt caught up to me. 😦

ahh, thanks.

I ended up implementing option 3 in https://github.com/kubernetes/kubernetes/pull/60522; it wasn’t quite as gross as I thought it’d be. LMK what you think.

/reopen

It looks like the 1.8 and 1.9 release branches are broken for the same reason, but the fix is a bit less trivial, since we can’t just use the latest gazelle, since this would require a huge mass of changes to the BUILD files. (Luckily, 1.7 doesn’t use gazelle, so it’s unaffected.)

Some additional background: gazelle doesn’t vendor bazelbuild/buildtools, though it does have a bazel dependency on a particular version. As a result, go get is always grabbing the latest version of bazelbuild/buildtools, even with our hacks to check out an older version of gazelle.

An additional complication for the 1.8 and 1.9 branches is that we’re installing gazelle from bazelbuild/rules_go instead of bazelbuild/bazel-gazelle.

Various options under consideration to fix these release branches:

  1. Fully vendor gazelle, similar to #57600 (but not a straight cherrypick, since versions are different)
  2. Clone the bazelbuild/rules_go repo somewhere (where?) and then explicitly vendor and older version of bazelbuild/buildtools, and then use that fork instead of the upstream fork
  3. Extend the hack in kube::util::go_install_from_commit() to also check out a particular bazelbuild/buildtools revision (so hacky)

Anyone have a better idea?