commit | 5e2133a1b300b7b0f80b8608136ccbbc9bfdf766 | [log] [tgz] |
---|---|---|
author | ulfjack <ulfjack@google.com> | Mon Sep 09 08:31:41 2019 -0700 |
committer | Copybara-Service <copybara-worker@google.com> | Mon Sep 09 08:33:23 2019 -0700 |
tree | 71f5a455e1f586808018ae1c3ed5806b6b6817fe | |
parent | b9591cfa68b6641dcf2e8d20b08bc518e3781055 [diff] |
Report a root cause in BEP on testonly violations Also move the VisibilityErrorEvent to the analysis package and rename it. Improve its documentation to clarify the intended use. This fixes the immediate issue, but does not address the underlying problem. The problem is that root cause analysis is incomplete, and reporting is disconnected. When we report the analysis failure of a target, we implicitly create a AnalysisFailedCause pointing at a root cause event, and hope that something else will post that. However, there's no guarantee that that ever happens, in which case we trigger a fail-safe in the BEP implementation, which posts an empty event and marks it as 'aborted' with no further explanation. We need to guarantee that we only report a root cause if there's a corresponding root cause event. The best way to do that is to collect the root cause events as causes, rather than creating a cause out of thin air. Common: event { id { target_completed { label: "//foo:foo" configuration { id: "b724944fdc6e8d9ab550b4b88f79644e" } } } children { configured_label { label: "//foo:foo" configuration { id: "b724944fdc6e8d9ab550b4b88f79644e" } } } aborted { reason: ANALYSIS_FAILURE } } Reported root cause before: event { id { configured_label { label: "//foo:foo" configuration { id: "b724944fdc6e8d9ab550b4b88f79644e" } } } aborted { } } Reported root cause after: event { id { configured_label { label: "//foo:foo" configuration { id: "b724944fdc6e8d9ab550b4b88f79644e" } } } aborted { reason: ANALYSIS_FAILURE description: "non-test target \'//foo:foo\' depends on testonly target \'//foo:bar\' and doesn\'t have testonly attribute set" } } PiperOrigin-RevId: 268003026
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel only rebuilds what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
See CONTRIBUTING.md
Bazel is released in ‘Beta’. See the product roadmap to learn about the path toward a stable 1.0 release.