feat(cloud-tasks): import the Java cloud-tasks service under Bazel#343
Open
balajinvda wants to merge 14 commits into
Open
feat(cloud-tasks): import the Java cloud-tasks service under Bazel#343balajinvda wants to merge 14 commits into
balajinvda wants to merge 14 commits into
Conversation
… hub Prepares the root nv_third_party_deps hub for the incoming cloud-tasks Java service (src/control-plane-services/cloud-tasks): - Add the 36 third-party coordinates cloud-tasks needs that were not already in the hub. All resolve from public Maven Central; the four BOMs it uses (spring-boot 4.0.7, spring-cloud 2025.1.2, testcontainers 2.0.5, shedlock 7.7.0) already match, so no version reconciliation was required. - Add gRPC-Java codegen support (rules_proto_grpc / rules_proto_grpc_java 5.8.0 plus the protoc-gen-grpc-java native plugin binaries) — the first Java gRPC consumer in the monorepo. - Re-pin //:maven_install.json. Note: pulling the grpc deps bumped the resolved rules_python and aspect_bazel_lib transitive versions above their direct pins (warnings only); those direct pins can be bumped separately. Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Important Review skippedToo many files! This PR contains 333 files, which is 33 over the limit of 300. To get a review, narrow the scope: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: ⛔ Files ignored due to path filters (5)
📒 Files selected for processing (333)
You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Adding cloud-tasks's grpc-java closure to the shared nv_third_party_deps hub pulled com.google.code.findbugs:jsr305 up from 2.0.1 to 3.0.2, which is a transitive dependency inside nv-boot-parent's own NOTICE closure. Regenerated nv-boot-parent/NOTICE (generate_notice.py --update-metadata --write) so notice_check_test matches the re-pinned lock. One version-string line changed. Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Relocate nvct-core + nvct-service to src/control-plane-services/cloud-tasks and build them with the monorepo-native //rules/java pattern (nvcf_java_library + nvcf_spring_boot_image + java_junit5_test), the same as examples/java-spring-boot-service. No rules_spring, no custom java/spring macros, no root-module change beyond the step-1 maven closure. nvct-core and nvct-service (:image_index) build green; nv-boot is consumed as in-tree source targets with no API drift. - gRPC-Java codegen retained via the subtree's proto.bzl; lombok wired through the subtree's own java_plugin. - CI: cloud-tasks is a root-workspace member (like nv-boot-parent), so it is covered by the root matrix row via ROOT_GLOBS rather than a nested-module row. - OSS hygiene: settings.xml (internal URM credential wiring) and the GitLab mirror .oss-allowlist are dropped from the public tree; urm.nvidia.com in pom.xml and stg.nvcr.io in test fixtures match content already public in the monorepo. local_env carries only dummy test fixtures. Follow-up: cloud-tasks NOTICE auto-verification was coupled to the rules_spring fat-jar layout and is removed with the macro swap; regenerating it for the exploded classpath needs the shared nv-boot generate_notice.py to support that layout (tracked separately). Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The pom.xml <repositories> block pointed at urm.nvidia.com (internal Artifactory) only to resolve the nv-boot parent for a Maven build. The monorepo builds cloud-tasks with Bazel and resolves nv-boot from in-tree source targets, so the Bazel/CI build never touches urm (0 urm URLs in the re-pinned maven_install.json). Remove the internal-server reference so the public GitHub tree does not advertise it; zero build impact. Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
🛡️ CodeQL Analysis🚨 Found 2 issue(s) Severity Breakdown:
📋 Top Issues🔗 View full details in Security tab 🕐 Last updated: 2026-07-22 14:28:27 UTC | Commit: 04e75eb |
…TICE Two root-row CI failures from landing cloud-tasks: - nvct-core:tests / nvct-service:tests are Testcontainers/Cassandra integration tests; the root row runs bazel test //... with no tag filter, so they ran on GHA (no Docker) and failed. Tag them "manual" so //... skips them; test sources still compile via :nvct_core_test_fixtures, and they stay runnable on demand in a Docker-capable environment. - Regenerate the root NOTICE (tools/scripts/update-license) to index the new src/control-plane-services/cloud-tasks/NOTICE. Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Testcontainers integration suites cannot run in the containerized bazel matrix (no Docker daemon), and skipping them is not acceptable. Add a dedicated bazel-integration lane that ports the proven GitLab recipe: a docker:dind service, the test process pointed at it via DOCKER_HOST, and Testcontainers told to reach spawned containers at the "docker" alias. - bazel-integration job: runs //... --test_tag_filters=requires-docker with the DinD service; exit 4 (no matching tests) is treated as success. - Fast matrix: excludes requires-docker (--test_tag_filters=-requires-docker); those tests still compile in the build step. - cloud-tasks nvct-core/nvct-service integration tests drop the interim "manual" tag and keep "requires-docker" so the lane runs them. cloud-tasks is the pilot; other services' skips (external / tests_skip) get removed as their suites are verified green in this lane. - bazel-verification gates on the lane's result. Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…+dind The container+docker:dind combination failed at actions/checkout (a known GHA rough edge with a service container attached to a containerized job). Switch the lane to the bare ubuntu-latest runner, which already has Docker running, so Testcontainers uses the host daemon directly -- no DinD service, no host-override networking, and no container+service checkout fragility. bazelisk reads .bazelversion for the pinned Bazel. Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…applies The integration tests failed under Bazel with InvalidKeyspaceException: keyspace nvct never got created. Root cause: Bazel test runfiles present local_env/** as symlinks into the build sandbox. The compose bind-mount ./cassandra/schema -> /docker-entrypoint-initdb.d then mounts a directory of dangling symlinks (their targets do not exist inside the Cassandra container), so entrypoint.sh finds no *.cql (log shows 'executing cql scripts' immediately followed by 'init scripts executed' with nothing in between) and the keyspace is never applied. Fix: the two filesystem resolution paths now copy the bundle into a directory of real files (dereferencing symlinks), the same way the JAR/Maven path already does via extractLocalEnvFromJar. The bind mounts then serve real content. No behavior change on a plain checkout (files are already real). Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- IntegrationTestConfiguration (Zip Slip, high): the JAR-extraction path now normalizes each destination and rejects any entry that resolves outside the extraction root, so a crafted '..' entry can no longer write outside it. - SecurityConfiguration (disabled CSRF, high): this is a stateless (SessionCreationPolicy.STATELESS) OAuth2 resource server authenticated by JWT/api-key bearer tokens with no cookies or sessions, so CSRF does not apply and disabling it is the correct Spring posture. Documented the rationale and added an inline CodeQL suppression rather than re-enabling (which would break the token-only API without adding protection). Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Pull the SpringDoc/OpenAPI 3.1 schema annotation fixes from the upstream
nvct/cloud-tasks feat/bazel branch (4c6f57c9) so the import tracks current
upstream. The DTOs declare explicit schema types (types={"object"}),
implementation, additionalProperties, and requiredMode so the generated
OpenAPI document is well-formed; MiscEndpointsTest asserts the affected
component schemas are objects.
Source-only sync: the monorepo's Bazel/OSS/CodeQL changes to
SecurityConfiguration.java and IntegrationTestConfiguration.java are strictly
ahead of upstream and are preserved untouched.
Co-authored-by: Balaji Ganesan <bganesan@nvidia.com>
… recognized The integration test's jar-extraction guard compared a normalized dest path against a non-normalized extraction root, which CodeQL does not recognize as a zip-slip sanitizer. Normalize the base once at definition so the dest.startsWith(base) check is the canonical normalized-to-normalized form. Behavior is unchanged (the extraction root has no `..`/symlink components); this only makes the existing guard statically provable and clears the CodeQL finding. Co-authored-by: Balaji Ganesan <bganesan@nvidia.com>
Move the Java tree off the shared root Maven hub and onto independent Bazel modules, so every Java library and service builds, tests, and pins its own dependencies from its own directory with no reference to the repo root. This brings Java to parity with the Go and Rust services, which are already self-contained nested modules with their own MODULE.bazel and CI matrix row. Modules created: - rules/java -> nvcf_java_rules: shared macros (nvcf_java_library, nvcf_spring_boot_image), platform.bzl (SPRING_BOOT_BOM, MAVEN_REPOSITORIES, version constants), a vendored self-contained create_oci_image (drops the //rules/oci dependency), and bom_alignment_test. - src/libraries/java/nv-boot-parent -> nv_boot_parent: the Spring platform library, its own @maven hub + maven_install.json, notice tooling repointed at the module-local lockfile. - src/control-plane-services/cloud-tasks -> nvct_cloud_tasks: the service, its own @maven hub (incl. gRPC codegen), depends on nvcf_java_rules + nv_boot_parent. - examples/java-spring-boot-service -> nvcf_java_example: the reference/template service, its own @maven hub. Migrated because it also consumed //rules/java and @nv_third_party_deps and would otherwise break the root build. Maven BOM alignment: load() is forbidden in MODULE.bazel, so each module inlines the canonical BOM list and guards it with bom_alignment_test, which fails the build if a module's boms drift from SPRING_BOOT_BOM in platform.bzl. This keeps the independent per-module resolutions in agreement without a shared hub. Root wiring: the four Java module paths (except rules/java, which declares no root-referencing targets) are added to .bazelignore; cloud-tasks is dropped from ROOT_GLOBS and src/libraries/ is narrowed to src/libraries/go/ so Java no longer rides the root row. bazel.yml gains nv-boot-parent, cloud-tasks, and java-spring-boot-service matrix rows (build + test); like all non-root rows they get EC2 Buildbarn cache hits via the workflow's remote-cache injection. CI image: ci/Dockerfile.bazel gains an additive remotejdk_25 + Bazel 9.1.1 pre-warm so the Java rows start warm; bazel-ci-image.yml bumps to 0.13.0 (builds on this PR, publishes on merge). The bazel.yml consumer ref stays at 0.12.0 until 0.13.0 is published, to keep the matrix from pinning an unpublished image. Maven jars are not baked (per-subtree actions/cache for now; see #373). Verified standalone from each module directory: nvcf_java_rules builds; nv_boot_parent builds + 17 non-docker tests pass (incl. bom_alignment_test, notice_check_test); nvct_cloud_tasks builds (gRPC codegen + nv_boot_parent consumed as a module) + bom_alignment_test passes; nvcf_java_example builds + 3 tests pass. Root workspace analyzes clean with the Java dirs ignored. Refs: #372 Co-authored-by: Balaji Ganesan <bganesan@nvidia.com>
# Conflicts: # .github/workflows/bazel.yml
|
🌿 Preview your docs: https://nvidia-preview-feat-cloud-tasks-bazel.docs.buildwithfern.com/nvcf |
… download The standalone Java modules pinned --java_runtime_version=remotejdk_25, so Bazel downloaded its own JDK 25 on every cold CI runner even though the bazel-ci image already ships Temurin 25 at JAVA_HOME. Point Bazel at that JDK via local_jdk, so there is no per-build JDK download and the image carries a single JDK. Also reverts the ci/Dockerfile.bazel + bazel-ci-image.yml prewarm changes: they are no longer needed because the image is unchanged and local_jdk uses the existing 0.12.0 Temurin. Supersedes the GitLab bazel-ci prewarm MR and the 0.13.0 image bump. Reproducibility now comes from the pinned CI image tag; local dev needs a JDK 25 on JAVA_HOME (to be revisited later). Co-authored-by: Balaji Ganesan <bganesan@nvidia.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Bring the
cloud-tasksJava service (NVCT) into the monorepo under Bazel atsrc/control-plane-services/cloud-tasks, as standalone Bazel modules. The upstream GitLab repo (nvcf/nvct/cloud-tasks,feat/bazel) stays source-of-truth while it stabilizes; this PR establishes the monorepo-native Bazel integration.Architecture
Java builds as standalone Bazel modules, not converged onto the root module.
nv-boot-parentandnvcf_java_rulesare their own modules (outside root), so every Java service depends on them and builds individually (bazel_dep+local_path_override).cloud-tasksis its own module depending on both.What's included
nvcf_java_rules(rules/java, shared macros +platform.bzl+ vendored OCI image helper),nv_boot_parent(own@mavenhub),nvct_cloud_tasks(own@mavenhub incl. gRPC codegen), and thenvcf_java_examplereference template.feat/bazel@4c6f57c9(OpenAPI 3.1 / SpringDoc schema annotations on the DTOs +MiscEndpointsTest).nv-boot-parent,cloud-tasks,java-spring-boot-service), all build and test;ROOT_GLOBSnarrowed tosrc/libraries/go/andcloud-tasksdropped from it (Java is its own row now). Rows receive the EC2 Buildbarn cache via the non-root injection block (Wire the EC2 Bazel remote cache for the standalone Java modules #372).remotejdk_25) + Bazel pre-warm inci/Dockerfile.bazel,bazel-ci-image.ymlbumped to0.13.0. Thebazel.ymlconsumer ref stays0.12.0until the image publishes on merge (see follow-up).Testing
nv-boot-parent(1025 actions, 17/17 tests incl.bom_alignment_test),cloud-tasks(1743 actions), example (build + 3 tests). Root analyzes clean.bazel integration (docker)(cloud-tasks DinD Cassandra integration) green on the synced source.Post-merge follow-up
bazel.ymlmatriximage:ref tobazel-ci:0.13.0after that image publishes on merge (bumping pre-merge would red every row).References
Related
nvcf/nvct/cloud-tasks(GitLab)feat/bazel.