| commit | 5a74742d83f1ff68e4d019eca6e4a0643a8eb2cb | [log] [tgz] |
|---|---|---|
| author | Googler <noreply@google.com> | Wed Oct 16 20:27:26 2019 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Oct 16 20:29:19 2019 -0700 |
| tree | 5eb7d7d0862dcf8bb47d2236f1e179d39af93499 | |
| parent | 48f6ddae5f6b12d80e1215964049bebbd5b8759c [diff] |
Fix doc formatting / style issues Fixed Markdown issues: * Ran mdformat * Put BUILD file last in examples, so that it's after the stuff it references * Changed language for .bzl file examples from python to bzl * Changed language for BUILD examples from python to build * Changed language for shell script examples from bash to shell * Changed language for shell command examples from python to shell Fixed style issues with examples: * Fixed indentation * List provider fields explicitly * Don't use predeclared outputs dict, which is deprecated * Just mention the names of keyword arguments instead of repeating the assertion example * Remove the comment about needing to call analysistest.begin before assertions, since the return-value of analysistest.begin is a parameter to the assertion methods. * Move the comment about analysistest.end next to that call. * There are a few places that touch on a distinction between the loading and analysis phase. Tried to make those a bit clearer about what happens when. * Prefix macros not intended to be used in the BUILD file with an underscore. * Have macros that are intended to be used in the BUILD file take a "name" attribute reflecting the name of the test-suite target. That makes the "top-level" test target name clear to readers of the build-file. * Suggest having test target names (as well as test rule names) end in "_test" * Suggest having test_suite target names end in "tests" (instead of "test") * Make the assertion under the "Verifying Registered Actions" example consistent with the behavior of the example rule. RELNOTES: Improve testing docs. PiperOrigin-RevId: 275171704
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only 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
