Fuchsia Integration Tests in Rust CI

# Fuchsia integration tests [Fuchsia](https://fuchsia.dev) is an open-source operating system with about 2 million lines of Rust code.[^loc] It has caught a large number of [regressions] in the past and was subsequently included in CI. ## What to do if the Fuchsia job breaks? Please contact the [fuchsia][fuchsia-ping] ping group and ask them for help. ```text @rustbot ping fuchsia ``` ## Building Fuchsia in CI Fuchsia builds as part of the suite of bors tests that run before a pull request is merged. If you are worried that a pull request might break the Fuchsia builder and want to test it out before submitting it to the bors queue, simply add this line to your PR description: > try-job: x86_64-fuchsia Then when you `@bors try` it will pick the job that builds Fuchsia. ## Building Fuchsia locally Because Fuchsia uses languages other than Rust, it does not use Cargo as a build system. It also requires the toolchain build to be configured in a [certain way][build-toolchain]. The recommended way to build Fuchsia is to use the Docker scripts that check out and run a Fuchsia build for you. If you've run Docker tests before, you can simply run this command from your Rust checkout to download and build Fuchsia using your local Rust toolchain. ``` src/ci/docker/run.sh x86_64-fuchsia ``` See the [Testing with Docker](../docker.md) chapter for more details on how to run and debug jobs with Docker. Note that a Fuchsia checkout is *large* – as of this writing, a checkout and build takes 46G of space – and as you might imagine, it takes a while to complete. ### Modifying the Fuchsia checkout The main reason you would want to build Fuchsia locally is because you need to investigate a regression. After running a Docker build, you'll find the Fuchsia checkout inside the `obj/fuchsia` directory of your Rust checkout. If you modify the `KEEP_CHECKOUT` line in the [build-fuchsia.sh] script to `KEEP_CHECKOUT=1`, you can change the checkout as needed and rerun the build command above. This will reuse all the build results from before. You can find more options to customize the Fuchsia checkout in the [build-fuchsia.sh] script. ### Customizing the Fuchsia build You can find more info about the options used to build Fuchsia in Rust CI in the [build_fuchsia_from_rust_ci.sh] script invoked by [build-fuchsia.sh]. The Fuchsia build system uses [GN], a metabuild system that generates [Ninja] files and then hands off the work of running the build to Ninja. Fuchsia developers use `fx` to run builds and perform other development tasks. This tool is located in `.jiri_root/bin` of the Fuchsia checkout; you may need to add this to your `$PATH` for some workflows. There are a few `fx` subcommands that are relevant, including: - `fx set` accepts build arguments, writes them to `out/default/args.gn`, and runs GN. - `fx build` builds the Fuchsia project using Ninja. It will automatically pick up changes to build arguments and rerun GN. By default it builds everything, but it also accepts target paths to build specific targets (see below). - `fx clippy` runs Clippy on specific Rust targets (or all of them). We use this in the Rust CI build to avoid running codegen on most Rust targets. Underneath

This section describes how Fuchsia is integrated into Rust's CI system, including how to handle breakages, build Fuchsia locally, modify the checkout, and customize the build. It explains the use of Docker scripts for building, the location of the Fuchsia checkout, and the tools like GN, Ninja, and fx used for building and development tasks.