Currently we specify --all-targets when building. It's equivalent of
--lib --bins --tests --benches --examples, but in test release jobs,
we don't need to build everything. So this PR reduces build target to only
--bin deno --bin test_server in build phase, and reduces test targets to
--bins --lib --tests.
This skips the building of benches and examples in test release jobs.
denort is an optimization to "deno compile" to produce slightly smaller
output. It's a decent idea, but causes a lot of negative side-effects:
- Deno's link time is a source of constant agony both locally and in CI,
denort doubles link time.
- The release process is a long and arduous undertaking with many manual
steps. denort necessitates an additional manual zip + upload from M1
apple computers.
- The "deno compile" interface is complicated with the "--lite" option.
This is confusing for uses ("why wouldn't you want lite?").
The benefits of this feature do not outweigh the negatives. We must find
a different approach to optimizing "deno compile" output.
We are aware that "lint debug ubuntu" and "test debug ubuntu" are sharing
caches - and that it is not ideal. Likely the lint cache will be written
first, and test-debug will have to build extra. However neither are the
bottleneck now.
We proceed on the assumption that we're hitting the 5 GB cache limit on a
single PR, inducing a forever-rolling behavior.
If "test debug ubuntu" becomes the bottleneck in the future we will
revisit.
There currently is a problem related to Github Actions in general or the
'actions-rs/cargo' action in particular, which causes cargo to be unable
to find the 'serde_derive' crate when the cargo home dir has been
restored from cache.
This issue is also being reported by others, e.g. at
actions-rs/cargo#111.
This removes the std folder from the tree.
Various parts of the tests are pretty tightly dependent
on std (47 direct imports and 75 indirect imports, not
counting the cli tests that use them as fixtures) so I've
added std as a submodule for now.
This commit adds new binary target called "denort".
It is a "lite" version of "deno" binary that can only execute
code embedded inside the binary itself.
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit updates CI script to publish only "deno"
crate on tags.
Following crates are not automatically published anymore:
- deno_core
- deno_web
- deno_fetch
- deno_crypto
Before this commit creating a new release required to bump
version on all above crates even though in practice they
rarely change.
This commit rewrites scripts in "tools/" directory
to use Deno instead of Python. In return it allows
to remove huge number of Python packages in "third_party/".
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.
