con un clic
nativelink-bazel-verification
// Use when verifying NativeLink changes with Bazel, selecting focused test targets, debugging rustfmt/clippy aspect failures, or preparing a confidence report for Rust/Bazel changes.
// Use when verifying NativeLink changes with Bazel, selecting focused test targets, debugging rustfmt/clippy aspect failures, or preparing a confidence report for Rust/Bazel changes.
Migrate a Bazel project from WORKSPACE to Bzlmod (MODULE.bazel). Use when a project has a WORKSPACE / WORKSPACE.bazel file but no MODULE.bazel, when the user asks to "migrate to bzlmod", "adopt MODULE.bazel", "drop WORKSPACE", "move to Bazel modules", or upgrade to Bazel 8/9 compatibility. Covers the hybrid WORKSPACE.bzlmod gradual migration, dependency translation (http_archive→bazel_dep, repo rules→use_repo_rule / module extensions, bind→alias), toolchain registration, override directives, the toolchainization pattern for rule-set authors, dual WORKSPACE/Bzlmod API design for library modules, minimum-version strategy with single_version_override, fixing Label(@computed_repo_name) patterns, and writing parameterized backwards-compatibility smoke tests.
Use when changing NativeLink JSON5 configuration, deployment examples, protobuf/service protocol surfaces, or compatibility-sensitive config behavior.
Use when updating NativeLink Cargo dependencies, Bazel module dependencies, rules_rust pins, lock files, toolchains, or generated dependency metadata.
Use when debugging NativeLink local remote execution, remote cache/executor self-tests, BEP event ingestion, worker scheduling, CAS misses, or Bazel remote execution behavior.
Use when implementing or reviewing Rust changes in NativeLink crates, especially storage, scheduler, worker, service, config, and shared utility behavior.
| name | nativelink-bazel-verification |
| description | Use when verifying NativeLink changes with Bazel, selecting focused test targets, debugging rustfmt/clippy aspect failures, or preparing a confidence report for Rust/Bazel changes. |
Use this skill when a NativeLink change needs a focused Bazel build/test plan, when CI reports a Bazel failure, or when you need to decide how much verification is enough.
BUILD.bazel files.nativelink-store/ for storage backends, CAS/AC, compression, Redis/S3/GCS/filesystem/memory stores.nativelink-scheduler/ for action scheduling and worker matching.nativelink-worker/ for local worker execution and action lifecycle.nativelink-service/ for REAPI, bytestream, BEP, and worker API services.nativelink-config/ for JSON5 configuration structs and examples.nativelink-util/ for shared helpers.nativelink-proto/ for protobuf-generated surfaces.Use the repository's Bazel defaults unless the user asked for a specific Bazel version.
bazel build //:nativelink
bazel build //...
bazel test //...
bazel test //nativelink-store:memory_store_test
bazel run --config=rustfmt @rules_rust//:rustfmt
For this workspace, when the user requests Bazelisk 9.0.2:
USE_BAZEL_VERSION=9.0.2 bazelisk --output_user_root=/tmp/bazelisk-9.0.2 --batch build //:nativelink
USE_BAZEL_VERSION=9.0.2 bazelisk --output_user_root=/tmp/bazelisk-9.0.2 --batch test //...
rustfmt fails, run:bazel run --config=rustfmt @rules_rust//:rustfmt
clippy fails, fix the code. Don't silence lints unless the suppression is local, justified, and consistent with existing code.//..., rerun the specific failing target with output enabled before editing.BUILD.bazel rather than guessing labels.Use the smallest rung that proves the change:
bazel build //:nativelink for server-path changes.bazel test //... for shared crates, proto/config surfaces, toolchain changes, or release confidence.Always report: