It seems that the inclusion of reverser.py in the .delete target pulls in the entire Python toolchain into runfiles.
|
"reverser": attr.label( |
|
default = Label("//k8s:reverser"), |
|
cfg = "target", |
|
executable = True, |
|
allow_files = True, |
|
), |
This causes the .delete target to be much larger than other targets by default.
❯ cat bazel-bin/my-container/k8s_my_container.apply.runfiles/MANIFEST | wc -l
22
❯ cat bazel-bin/my-container/k8s_my_container.delete.runfiles/MANIFEST | wc -l
4290
We build 1800 k8s_objects during CI, so this expands to about 8 million runfiles, which causes disk contention populating the runfiles dir on clean builds, which leads to long build times and inode exhaustion issues on some of our (admittedly aging) build infrastructure. This doesn't seem to be an issue with the Go-based resolver included in the other targets, which only adds one target (the built resolver binary).
I can see two ways around this, either by introducing a selector (likely here) that lets us choose which targets we want to generate (resolve, apply, diff, etc) or porting the reverser to Go so that it models the resolver.
I have the time to implement either solution, just looking for some feedback before opening a PR.
It seems that the inclusion of
reverser.pyin the.deletetarget pulls in the entire Python toolchain into runfiles.rules_k8s/k8s/object.bzl
Lines 420 to 425 in 8b96841
This causes the
.deletetarget to be much larger than other targets by default.We build 1800 k8s_objects during CI, so this expands to about 8 million runfiles, which causes disk contention populating the runfiles dir on clean builds, which leads to long build times and inode exhaustion issues on some of our (admittedly aging) build infrastructure. This doesn't seem to be an issue with the Go-based resolver included in the other targets, which only adds one target (the built resolver binary).
I can see two ways around this, either by introducing a selector (likely here) that lets us choose which targets we want to generate (resolve, apply, diff, etc) or porting the reverser to Go so that it models the resolver.
I have the time to implement either solution, just looking for some feedback before opening a PR.