We are using Bazel to build and test with remote cache. And when running bazel test, sometimes Bazel reports that the remote cache hits number is greater than the total actions number. In which cases can this happen? I just assume that the remote cache hit should always less than the total actions.
The Bazel version we are using is 3.7.0
Bazel documentation suggests:
If you are getting 0 processes (or a number lower than expected), run bazel clean followed by your build/test command.
Maybe for some reason your cache is "damaged".
Related
I observe that my Bazel build agent frequently builds the project from scratch (including compiling grpc, which keeps unchanged) instead of taking results from cache. Is there a way, like query or cquery (pardon my ignorance) to determine why is the cache considered invalid for particular target? Or any techniques to tackle cache invalidation problem?
This is How the bazel build works :
When running a build or a test, Bazel does the following: Loads the BUILD files relevant to the target. Analyzes the inputs and their dependencies, applies the specified build rules, and produces an action graph. Executes the build actions on the inputs until the final build outputs are produced.
If you are having any clear assumptions can you please share the complete details!
This is most likely due to the rebuild sensitivity to particular environment variables. Many build actions will read from environment variables and use them to change the outputs. Bazel keeps track of this and will rebuild seemingly unchanged remote targets when your env changes.
To demonstrate this;
Build grpc (2x ensure it is cached the second time)
Change the PATH environment variable (your IDE may do this without you knowing)
mkdir ~/bin && export PATH=$PATH:~/bin
Rebuild grpc (This should trigger a complete rebuild)
There are a couple helpful flags to combat this rebuild sensitivity, and I'd recommend adding them to your bazelrc.
incompatible_strict_action_env: Freezes your environment and doesn't source environment variables from your shell.
action_env modify environment variables as needed for you build.
# file //.bazelrc
# Don't source environment from shell
build --incompatible_strict_action_env
# Use action_env as needed for your project
build --action_env=CC=clang
I want to run e2e tests using Bazel.
Each Bazel e2e test rule requires a unique set of external services. For example, some e2e tests might require postgresql, others might require kafka, etc.
I don't want to stand up all these services before every single test run. Instead, I want to query the Bazel cache. If tests already passed and cached results remain valid, I would skip external service setup.
How can I query the Bazel cache to see which of my tests have already passed and won't rerun?
Provided you keep your Bazel server running, and don't change any dependencies (test files, source files, Bazel target configs), Bazel automatically caches passing tests.
In other words, if I run:
bazel test //foo:bar
The first time, bazel builds and executes the test. If I leave the Bazel server up and rerun
bazel test //foo:bar
...bazel returns rather quickly, and notes that you had a cache hit:
//foo:bar (cached) PASSED in 0.1s
Please let me know if I've misunderstood your question.
As part of our efforts to create a bazel-maven transition interop tool (that creates maven sized jars from more granular sized bazel jars),
we have written an aspect that runs on bazel build of the entire bazel repo and writes txt files outputs.
We want to write these aspect outputs only for non-cashed targets.
Even better will be to have a list at the end of the run that contains all the targets that were run (not skipped due to them being cached)
Are 1. and 2. possible?
We want to write these aspect outputs only for non-cashed targets.
I am not 100% sure what you mean here. It is undetectable if the target was cached or not. However, output files will be cached. If you run the same build with the same aspect, only the files that are not up-to-date will be updated.
... to have a list at the end of the run that contains all the targets that were run
We have a flag --experimental_show_artifacts that prints you all the artifacts that were built.
I'm trying to analyze and fix a flaky test which is often green.
My problem is that once the test passes Bazel doesn't re-run it until any of the inputs have changed.
I saw you can ask Bazel to re-run a target but AFAICT it's only until the first time it's green (i.e. to mitigate a flaky test and not solve it).
Is there a way to ask Bazel to run the test even if it passed?
I'd like something like bazel test --force-attempts=50 //my-package:my-target
There's a flag for it
--cache_test_results=(yes|no|auto) (-t)
If this option is set to 'auto' (the default) then Bazel will only rerun a test if any of the following conditions applies:
Bazel detects changes in the test or its dependencies
the test is marked as external
multiple test runs were requested with --runs_per_test
the test failed.
If 'no', all tests will be executed unconditionally.
If 'yes', the caching behavior will be the same as auto except that it may cache test failures and test runs with --runs_per_test.
Note that test results are always saved in Bazel's output tree, regardless of whether this option is enabled, so you needn't have used --cache_test_results on the prior run(s) of bazel test in order to get cache hits. The option only affects whether Bazel will use previously saved results, not whether it will save results of the current run.
Users who have enabled this option by default in their .bazelrc file may find the abbreviations -t (on) or -t- (off) convenient for overriding the default on a particular run.
https://docs.bazel.build/versions/master/user-manual.html#flag--cache_test_results
In addition to --cache_test_results, Bazel actually has a flag specifically designed for diagnosing flaky tests: --runs_per_test, which will rerun a test N times and only keep logs from the failing runs:
$ bazel test --runs_per_test=10 :flaker
INFO: Found 1 test target...
FAIL: //:flaker (run 10 of 10) (see /output/testlogs/flaker/test_run_10_of_10.log).
FAIL: //:flaker (run 4 of 10) (see /output/testlogs/flaker/test_run_4_of_10.log).
FAIL: //:flaker (run 5 of 10) (see /output/testlogs/flaker/test_run_5_of_10.log).
FAIL: //:flaker (run 9 of 10) (see /output/testlogs/flaker/test_run_9_of_10.log).
FAIL: //:flaker (run 3 of 10) (see /output/testlogs/flaker/test_run_3_of_10.log).
Target //:flaker up-to-date:
bazel-bin/flaker
INFO: Elapsed time: 0.828s, Critical Path: 0.42s
//:flaker FAILED
Executed 1 out of 1 tests: 1 fails locally.
You can use it to quickly figure out how flaky a test is and get some failing logs.
Hi guys when I use Jenkins+Maven+Sonar
I found that when I delete a project in sonar and then I run the job in Jenkins
the total project number in sonar is never reduced . It just repeated increment .
Even I deleted the database and run again the number of project in sonar cant be reduced.
Is there some cache in sonar?
How can I reset the number of project?
This is likely caused by a corrupted Elasticsearch index. Shut down your server, delete $SONARQUBE_HOME/data and restart.