local_repository vs http_archive for Private Dependencies Under Hermetic Sandbox

Answer

For a private dependency that must build identically on a developer laptop, in CI, and on remote executors without manually provisioning host paths, the recommended approach is to use http_archive pointing to an internal artifact server with a declared sha256 and to ensure the artifact is pre‑populated in the remote execution cache. This satisfies hermeticity and reproducibility while keeping the developer workflow fast.

Confirmed facts

• local_repository binds the workspace to an absolute host path; under Bazel’s hermetic sandbox (--incompatible_strict_action_env) the build fails in CI or remote execution when that path is missing or inaccessible.
• http_archive fetches a tarball from a URL and validates it with a declared sha256. When the artifact is served by an internal mirror and the hash matches, the same WORKSPACE or MODULE.bazel definition works unchanged on a developer machine (if the internal mirror is reachable) and in CI/remote execution without any host‑path mounts.
• Vendoring (checking the dependency source into the repository) eliminates both network fetches and host‑path reliance, but it increases repository size and requires committing updates whenever the dependency changes.

Steps to implement the http_archive solution

1. Publish the private dependency as a versioned tarball (e.g., mydep-1.2.3.tar.gz) to an internal artifact server that is accessible from developer machines and from the remote execution environment.
2. Compute the sha256 of the tarball and record it in the WORKSPACE or MODULE.bazel definition:

http_archive(
    name = "my_private_dep",
    urls = ["https://internal-artifacts.example.com/mydep-1.2.3.tar.gz"],
    sha256 = "abcd1234..."  # replace with actual hash
)

3. Ensure the remote execution cache is primed with this artifact (e.g., by running a warm‑up build on a dedicated runner or by using Bazel’s remote cache warm‑up feature). After priming, subsequent remote builds will retrieve the artifact from the cache rather than attempting network egress.
4. Build with hermetic sandbox enforcement to verify correctness:

bazel build //... --incompatible_strict_action_env

5. On a developer laptop, confirm that the build succeeds without needing to mount any host directory; the fetch will go to the internal server (or the local HTTP cache if already downloaded).

When vendoring might be preferable

If the dependency is very small, changes infrequently, and the team accepts the extra repository size, vendoring removes the need for an internal server and guarantees zero‑network fetches. However, this approach trades maintenance overhead for simplicity and may not scale well for larger binaries or frequently updated libraries.

Missing diagnostic detail that could change the recommendation

Knowing the approximate size of the private dependency and how often it updates would help decide whether the maintenance cost of vendoring outweighs the operational overhead of running an internal artifact server. If the artifact is large (> 100 MB) or updated weekly, the internal server with pre‑seeded cache is clearly lower‑maintenance; if it is tiny (< 1 MB) and stable, vendoring becomes a viable alternative.