-
Notifications
You must be signed in to change notification settings - Fork 440
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci.bazel.io job fails with latest build #3
Comments
@davidzchen ping? |
We will need to remove |
That is not enough, you also have 2 other tests that fails. Maybe mark them as manual? |
Which other two? The logs only indicate one:
The failing test |
//examples/hello_lib:hello_lib_doc_test PASSED in 0.2s Executed 2 out of 10 tests: 8 tests pass, 1 fails to build and 1 fails locally. http://ci.bazel.io/job/rules_rust/56/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/console The other two might be flaky |
Oh sorry, use the tags "noci" should exclude it. |
…_job Build targets are build in another target and unselected targets might be build if we do not add that tag. Bazel tests include it and rust need it. Fixes bazelbuild/rules_rust#3 Change-Id: Idf54f84bf6668f86d5d308041a4ccf3533e4bec3
It's blue now :) |
Thanks! |
As discussed in bazelbuild#3
bazelbuild#1: Include details such as the target architecture in the cache folder hash. Previously only the path to rustc and the compilation mode was used to calculate the hash, and this was likely the cause of ICEs. We now include all of the env vars passed into the request in the hash, so that separate folders are created for different crate names, crate versions, and target architectures. bazelbuild#2: A new worker was previously being created for every rustc invocation, because the env parameter contained crate-specific details that caused WorkerKey to change each time. Instead of passing the environment in directly, persist it to a file, and pass it to process-wrapper with --env-file instead. We also use the contents of this file in order to generate the hash mentioned above. This will mean you'll be limited to 4 workers by default; you may want to also pass in --worker_max_instances=Rustc=HOST_CPUS*0.5 or similar, as JIT startup is not a concern for the Rust workers, and parts of rustc's compilation process are unable to take advantage of more than 1 CPU core. bazelbuild#3: Instead of storing incremental files in $TEMP, the worker is now enabled by providing it with a folder that it should store its incremental files in, such as: bazel build --@rules_rust//worker:cache_root=/path/to/cache/files This mimics the behaviour of --disk_cache and --repository_cache, and makes it clear where the files are being persisted to.
Due to some problems in rust:
http://ci.bazel.io/job/rules_rust/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/36/console
The text was updated successfully, but these errors were encountered: