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
- Merge pull request #60442 from mikedanese/fix-bzl Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.c... — committed to aledbf/kubernetes by deleted user 6 years ago
- Merge pull request #60523 from ixdy/1.8-gazelle-buildtools-constraint Automatic merge from submit-queue. hack: when installing gazelle, checkout older version of buildtools **What this PR does / wh... — committed to kubernetes/kubernetes by deleted user 6 years ago
- Merge pull request #60522 from ixdy/1.9-gazelle-buildtools-constraint Automatic merge from submit-queue. hack: when installing gazelle, checkout older version of buildtools **What this PR does / wh... — committed to kubernetes/kubernetes by deleted user 6 years ago
@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 getis 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:
kube::util::go_install_from_commit()to also check out a particular bazelbuild/buildtools revision (so hacky)Anyone have a better idea?