This is the release commit being forwarded back to main for 1.44.1
Co-authored-by: devsnek <devsnek@users.noreply.github.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Fixes the sysroot to make it more reliable on aarch64. The sysroot we
download as part of the build process now includes a small script to set
up the linker flags required to build in that sysroot.
Fixes #23775
Before:
```
matt@raspberrypi:~ $ ~/.deno/bin/deno
/home/matt/.deno/bin/deno: /lib/aarch64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by /home/matt/.deno/bin/deno)
```
After:
```
matt@raspberrypi:/tmp $ ./deno
Deno 1.43.3
exit using ctrl+d, ctrl+c, or close()
REPL is running with all permissions allowed.
To specify permissions, run `deno repl` with allow flags.
```
**THIS PR HAS GIT CONFLICTS THAT MUST BE RESOLVED**
This is the release commit being forwarded back to main for 1.43.2
Please ensure:
- [x] Everything looks ok in the PR
- [x] The release has been published
To make edits to this PR:
```shell
git fetch upstream forward_v1.43.2 && git checkout -b forward_v1.43.2 upstream/forward_v1.43.2
```
Don't need this PR? Close it.
cc @nathanwhit
Co-authored-by: nathanwhit <nathanwhit@users.noreply.github.com>
Co-authored-by: Nathan Whitaker <nathan@deno.com>
Fixes CI. The wpt setup script writes to `/etc/hosts` which now needs
`--allow-all`. We use the latest release for the deno binary there so
it's only impacted as of the 1.43.0 release.
The `tools/node_compat/node` submodule has been moved to
`tests/node_compat/runner/suite` and the remaining files within
`tools/node_compat` to `tests/node_compat/runner`.
Most of the changes are of the header within `tests/node_compat/test`
files. The `setup` and `test` tasks within `tests/node_comapt` execute
successfully.
Towards #22525
CC @mmastrac
This is the release commit being forwarded back to main for 1.41.2
Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Removes the following warning on the `wpt_epoch` CI workflow:
```
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3, denoland/setup-deno@v1, actions/setup-python@v4. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.
```
Co-authored-by: Matt Mastracci <matthew@mastracci.com>
Having `|| true` means that the job always executes with a success code,
even when it really fails. Credit to Bartek for spotting this possible
mistake.
Towards #22257
denort are release binaries for `deno compile`. Stripping debuginfo and
symbols lets us ship a smaller binary. The same source can be run under
`deno` CLI to get the proper Rust backtrace.
stripped denort is 55MB on macOS.
Note: tests are not the only part of the codebase that uses `std`. Other
parts, like `tools/`, do too. So, it could be argued that this is a
little misleading. Either way, I'm doing this as discussed with
@mmastrac.
This introduces the `denort` binary - a slim version of deno without
tooling. The binary is used as the default for `deno compile`.
Improves `deno compile` final size by ~2.5x (141 MB -> 61 MB) on Linux
x86_64.
This PR separates integration tests from CLI tests into a new project
named `cli_tests`. This is a prerequisite for an integration test runner
that can work with either the CLI binary in the current project, or one
that is built ahead of time.
## Background
Rust does not have the concept of artifact dependencies yet
(https://github.com/rust-lang/cargo/issues/9096). Because of this, the
only way we can ensure a binary is built before running associated tests
is by hanging tests off the crate with the binary itself.
Unfortunately this means that to run those tests, you _must_ build the
binary and in the case of the deno executable that might be a 10 minute
wait in release mode.
## Implementation
To allow for tests to run with and without the requirement that the
binary is up-to-date, we split the integration tests into a project of
their own. As these tests would not require the binary to build itself
before being run as-is, we add a stub integration `[[test]]` target in
the `cli` project that invokes these tests using `cargo test`.
The stub test runner we add has `harness = false` so that we can get
access to a `main` function. This `main` function's sole job is to
`execvp` the command `cargo test -p deno_cli`, effectively "calling"
another cargo target.
This ensures that the deno executable is always correctly rebuilt before
running the stub test runner from `cli`, and gets us closer to be able
to run the entire integration test suite on arbitrary deno executables
(and therefore split the build into multiple phases).
The new `cli_tests` project lives within `cli` to avoid a large PR. In
later PRs, the test data will be split from the `cli` project. As there
are a few thousand files, it'll be better to do this as a completely
separate PR to avoid noise.
