A recent change in rustc or cargo made it so that rusty_v8's `build.rs`,
which is responsible for downloading `librusty_v8.a`, does not get
rebuilt or re-run when its build output directory is restored from the
Github Actions cache.
However, rusty_v8's custom build script does not save the download to
its build output directory; it puts the file in
`target/debug|release/gn_out/obj` instead.
To get CI going again we opted to add `target/*/gn_out` to the Github
Actions cache.
A more robust fix would be make rusty_v8 save the download to the
cargo-designated output directory.
All benchmarks are done in Rust and can be invoked with
`cargo bench`.
Currently this has it's own "harness" that behaves like
`./tools/benchmark.py` did.
Because of this tests inside `cli/bench` are currently not run.
This should be switched to the language provided harness
once the `#[bench]` attribute has been stabilized.
Before this commit, when Cargo.lock changes, cache is completely rebuilt, wasting time.
After this commit, if cache for a specific Cargo.lock is not found, it will fallback to find cache of another Cargo.lock.
* Remove DENO_BUILD_MODE and DENO_BUILD_PATH
Also remove outdated docs related to ninja/gn.
* fix
* remove parameter to build_mode()
* remove arg parsing from benchmark.py
The test still relies on crates published to crates.io, thus this test
prevents us from making changes to the API used between cli and
deno_typescript.
It was found the cargo-package-dry-run test would fail when version
numbers are bumped because crates were not actually published. So, for
example, deno_typescript 0.30.2 would not be able to find deno_core
0.30.2 because it had not yet been published (see #3744).
Ref #3712
