This adds a daily scheduled CI pipeline that runs WPT tests against
the most recent epochs/daily every night. Results are uploaded to
wpt.fyi.
WPTs are run on all supported platforms, on both stable and canary.
These reports can be consumed by tools like `wptreport` or
https://wpt.fyi. The old style report could be removed in a future PR
when wpt.deno.land is updated.
Note that Rust 1.51.1 adds extra verification to avoid miscompiles, so it
is possible that this PR causes build failures on CI, in which case it
needs to be reverted.
See https://blog.rust-lang.org/2021/05/10/Rust-1.52.1).
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.
