bazelbuild / bazelbuild/bazel

No way to run tests in bzlmod dependency if they depend on dev_dependency

Open
#22,187 4 comments 0 reactions 0 assignees View on GitHub
area-Bzlmod help wanted P3 team-ExternalDeps type: feature request
Dominant language
Java
Stars
25.8k
Forks
4.6k
Avg merge
2d 20h
Merged PRs (30d)
72

Description

### Description of the bug:

Based on https://github.com/bazelbuild/bazel-central-registry/pull/1833#issuecomment-2083516837, I gather best practice for bzlmod is to mark your tests' dependencies as a dev_dependency. We've thus tentatively set googletest as a dev_dependency in BoringSSL.

Now, suppose someone consuming BoringSSL wants to run the tests anyway. For example, they may have some issue and we might ask them to run the tests and confirm it's not a toolchain problem. This then fails because the dependency is missing:

```
Starting local Bazel server and connecting to it...
ERROR: no such package '@@[unknown repo 'googletest' requested from @@boringssl~]//': The repository '@@[unknown repo 'googletest' requested from @@boringssl~]' could not be resolved: No repository visible as '@googletest' from repository '@@boringssl~'
ERROR: /usr/local/google/home/davidben/.cache/bazel/_bazel_davidben/11e4cdfc071b85e46241e062520598c0/external/boringssl~/BUILD.bazel:93:13: no such package '@@[unknown repo 'googletest' requested from @@boringssl~]//': The repository '@@[unknown repo 'googletest' requested from @@boringssl~]' could not be resolved: No repository visible as '@googletest' from repository '@@boringssl~' and referenced by '@@boringssl~//:crypto_test'
ERROR: Analysis of target '@@boringssl~//:crypto_test' failed; build aborted: Analysis failed
INFO: Elapsed time: 4.755s, Critical Path: 0.03s
INFO: 1 process: 1 internal.
ERROR: Build did NOT complete successfully
ERROR: No test targets were found, yet testing was requested
FAILED:
Fetching repository @@bazel_tools~cc_configure_extension~local_config_cc; starting
```

The same error occurs if I explicitly pull in `googletest` from the downstream module. As far as I can tell, there is no way to go back and tell `boringssl` that I do indeed have a `googletest` for you.

### Which category does this issue belong to?

External Dependency

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

```
git clone https://boringssl.googlesource.com/boringssl
cd boringssl
git checkout 70d05d5a34f6366116e2b0a530ea8d0186bb2a8e
cd util/bazel-example
bazelisk test @boringssl//:crypto_test
echo 'bazel_dep(name = "googletest", version = "1.14.0.bcr.1")' >> MODULE.bazel
bazelisk test @boringssl//:crypto_test
```

### Which operating system are you running Bazel on?

Linux

### What is the output of `bazel info release`?

release 7.1.1

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

```text
https://boringssl.googlesource.com/boringssl
70d05d5a34f6366116e2b0a530ea8d0186bb2a8e
```

### Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

_No response_

### Have you found anything relevant by searching the web?

_No response_

### Any other information, logs, or outputs that you want to share?

_No response_

Contributor guide

Open the contributing guide

Research direction

Start with the reproduction in util/bazel-example, including its MODULE.bazel and the @boringssl//:crypto_test target, and run the two bazelisk test commands shown. Read the resulting dependency-resolution behavior for googletest when it is declared as a dev_dependency. Done means a downstream consumer can explicitly provide the dependency and run the BoringSSL test target successfully.

Written by the indexing model from the issue text.

Assessment

Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.