Context
Java services are moving to standalone Bazel modules: nv-boot-parent and nvcf_java_rules live outside the root module, and each Java service (starting with cloud-tasks) is its own module that bazel_deps them and builds individually.
Today cloud-tasks builds inside the root module: .github/workflows/bazel.yml includes src/control-plane-services/cloud-tasks/ in ROOT_GLOBS, so it inherits the root job's --config=remote and gets EC2 Buildbarn cache hits. Once it becomes its own module it drops out of ROOT_GLOBS and loses cache coverage unless the cache is wired explicitly, the same way the other service modules get it.
Current gap
rules/java/.bazelrc has no remote-cache config.- There is no
src/control-plane-services/cloud-tasks/.bazelrc and no dedicated matrix row for it.
- Service modules do not set
--config=remote; the workflow injects --remote_cache / --tls_certificate / --remote_header=authorization=Bearer for them. The Java modules must opt into that path (or set an equivalent config) or their CI builds go cache-cold.
What to wire
- Matrix row(s) in
.github/workflows/bazel.yml for the standalone Java module(s), is_root=false, and remove cloud-tasks/ from ROOT_GLOBS when it becomes its own module.
- Confirm the non-root cache-injection block covers the Java build (endpoint
BAZEL_REMOTE_CACHE_ENDPOINT, BAZEL_REMOTE_CACHE_CA, token BAZEL_REMOTE_CACHE_TOKEN).
- Release path:
nvcf-internal tools/ci/build_bazel_release_manifest.sh already probes the CI-variable-driven EC2 endpoint; verify it works for a Java type: bazel build.
- Verify: a cold vs warm CI run shows remote cache hits for the Java module; no Java module builds cache-cold.
Acceptance
Standalone Java module CI builds show EC2 Buildbarn cache hits and no module is silently cache-cold after the root-module split.
Relates to #343 (cloud-tasks import) and the standalone Java module work.
Context
Java services are moving to standalone Bazel modules:
nv-boot-parentandnvcf_java_ruleslive outside the root module, and each Java service (starting withcloud-tasks) is its own module thatbazel_deps them and builds individually.Today
cloud-tasksbuilds inside the root module:.github/workflows/bazel.ymlincludessrc/control-plane-services/cloud-tasks/inROOT_GLOBS, so it inherits the root job's--config=remoteand gets EC2 Buildbarn cache hits. Once it becomes its own module it drops out ofROOT_GLOBSand loses cache coverage unless the cache is wired explicitly, the same way the other service modules get it.Current gap
rules/java/.bazelrchas no remote-cache config.src/control-plane-services/cloud-tasks/.bazelrcand no dedicated matrix row for it.--config=remote; the workflow injects--remote_cache/--tls_certificate/--remote_header=authorization=Bearerfor them. The Java modules must opt into that path (or set an equivalent config) or their CI builds go cache-cold.What to wire
.github/workflows/bazel.ymlfor the standalone Java module(s),is_root=false, and removecloud-tasks/fromROOT_GLOBSwhen it becomes its own module.BAZEL_REMOTE_CACHE_ENDPOINT,BAZEL_REMOTE_CACHE_CA, tokenBAZEL_REMOTE_CACHE_TOKEN).nvcf-internal tools/ci/build_bazel_release_manifest.shalready probes the CI-variable-driven EC2 endpoint; verify it works for a Javatype: bazelbuild.Acceptance
Standalone Java module CI builds show EC2 Buildbarn cache hits and no module is silently cache-cold after the root-module split.
Relates to #343 (cloud-tasks import) and the standalone Java module work.