Fuchsia 統合テスト

Fuchsia は、約 200 万行の Rust コードを持つオープンソースのオペレーティングシステムです。¹ 過去に多数の regressions を検出しており、その後 CI に含められました。

Fuchsia ジョブが壊れた場合はどうすればよいですか？

fuchsia ping グループに連絡し、支援を依頼してください。

@rustbot ping fuchsia

CI で Fuchsia をビルドする

Fuchsia は、プルリクエストがマージされる前に実行される bors テストスイートの一部としてビルドされます。

プルリクエストによって Fuchsia ビルダーが壊れる可能性を懸念しており、 bors キューに送信する前にテストしたい場合は、Fuchsia 統合をビルドする try ジョブを実行するよう bors に依頼するだけです: @bors try jobs=x86_64-fuchsia。

Fuchsia をローカルでビルドする

Fuchsia は Rust 以外の言語を使用しているため、ビルドシステムとして Cargo を使用していません。また、ツールチェーンのビルドが特定の方法で構成されている必要もあります。

Fuchsia をビルドする推奨方法は、Fuchsia のチェックアウトとビルドを代わりに実行する Docker スクリプトを使用することです。以前に Docker テストを実行したことがある場合は、 Rust チェックアウトから次のコマンドを実行するだけで、ローカルの Rust ツールチェーンを使用して Fuchsia をダウンロードしてビルドできます。

src/ci/docker/run.sh x86_64-fuchsia

Docker でジョブを実行およびデバッグする方法の詳細については、 Testing with Docker の章を参照してください。

Fuchsia のチェックアウトは大きいことに注意してください。本稿執筆時点では、チェックアウトとビルドには 46G の容量が必要であり、想像できるとおり、完了までにしばらく時間がかかります。

Fuchsia をローカルでビルドしたい主な理由は、リグレッションを調査する必要があるためです。Docker ビルドを実行した後、Rust チェックアウトの obj/fuchsia ディレクトリ内に Fuchsia のチェックアウトがあります。 build-fuchsia.sh スクリプトの KEEP_CHECKOUT 行を KEEP_CHECKOUT=1 に変更すると、必要に応じてチェックアウトを変更し、上記のビルドコマンドを再実行できます。これにより、以前のすべてのビルド結果が再利用されます。

Fuchsia チェックアウトをカスタマイズするためのその他のオプションは、 build-fuchsia.sh スクリプトで確認できます。

Fuchsia ビルドをカスタマイズする

Rust CI で Fuchsia をビルドするために使用されるオプションの詳細は、 build-fuchsia.sh によって呼び出される build_fuchsia_from_rust_ci.sh スクリプトで確認できます。

Fuchsia のビルドシステムは GN を使用します。これは Ninja ファイルを生成し、その後ビルドを実行する作業を Ninja に引き渡すメタビルドシステムです。

Fuchsia 開発者は fx を使用してビルドを実行し、その他の開発タスクを行います。このツールは Fuchsia チェックアウトの .jiri_root/bin にあります。一部のワークフローでは、これを $PATH に追加する必要があるかもしれません。

関連する fx サブコマンドがいくつかあります。たとえば次のとおりです。

fx set はビルド引数を受け取り、それを out/default/args.gn に書き込み、 GN を実行します。
fx build は Ninja を使用して Fuchsia プロジェクトをビルドします。ビルド引数への変更を自動的に検出して GN を再実行します。デフォルトではすべてをビルドしますが、特定のターゲットをビルドするためのターゲットパスも受け付けます（下記参照）。
fx clippy は特定の Rust ターゲット（またはそのすべて）に対して Clippy を実行します。Rust CI ビルドでは、ほとんどの Rust ターゲットで codegen を実行しないようにするため、これを使用します。内部では、 fx build と同様に Ninja を呼び出します。clippy の結果は、出力される前にビルド出力ディレクトリ内の json ファイルに保存されます。

ターゲットパス

GN は次のようなパスを使用してビルドターゲットを識別します。

//src/starnix/kernel:starnix_core

先頭の // はチェックアウトのルートを意味し、残りのスラッシュはディレクトリ名です。: の後の文字列は、そのディレクトリの BUILD.gn ファイルで定義されたターゲットの ターゲット名 です。

ターゲット名がディレクトリ名と同じ場合は省くことができます。言い換えると、 //src/starnix/kernel は //src/starnix/kernel:kernel と同じです。

これらのターゲットパスは、依存関係を参照するために BUILD.gn ファイル内で使用され、 fx build でも使用できます。

コンパイラフラグを変更する

ターゲットに追加される GN config の中にカスタムコンパイラフラグを入れることができます。簡単な例を示します。

config("everybody_loops") {
    rustflags = [ "-Zeverybody-loops" ]
}

rustc_binary("example") {
    crate_root = "src/bin.rs"
    # ...既存のキーをここに...
    configs += [ ":everybody_loops" ]
}

これにより、example ターゲットをビルドするときに rustc に -Zeverybody-loops フラグが追加されます。あるターゲットに依存するすべてのターゲットに config を追加するために public_configs も使用できることに注意してください。

ビルド内のすべての Rust ターゲットにフラグを追加したい場合は、 rustflags を //build/config:compiler config、またはそのファイルから参照される OS 固有の config に追加できます。Rust ターゲットでは cflags と ldflags は無視されることに注意してください。

ninja と rustc コマンドを直接実行する

1 レイヤー下に進むと、fx build は ninja を呼び出し、さらにそれが最終的に rustc を呼び出します。すべてのビルドアクションは out ディレクトリ内で実行されます。これは通常、 Fuchsia チェックアウト内の out/default です。

ninja が呼び出す実際のコマンドを表示させるには、そのコマンドが失敗するように強制します。たとえば、ターゲットのソースファイルの 1 つに構文エラーを追加します。コマンドを取得したら、出力ディレクトリ内からそれを実行できます。

ツールチェーン自体を変更した後は、fx build または ninja がすべての Rust ターゲットを再ビルドするように、out/default/args.gn 内のビルド設定 rustc_version_string を変更する必要があります。これはテキストエディターで行うことができ、文字列の内容は、あるビルドから次のビルドへ変化している限り重要ではありません。 build_fuchsia_from_rust_ci.sh は、ツールチェーンディレクトリをハッシュすることでこれを行います。

Fuchsia のウェブサイトには、build system のより詳細なドキュメントがあります。

その他のヒントとテクニック

build_fuchsia_from_rust_ci.sh を使用するときは、初回実行後に fx set コマンドをコメントアウトして、毎回 GN が再実行されないようにできます。これを行う場合は、 version_string 行もコメントアウトして数秒節約できます。

初回ビルド後の ninja の起動時間を短縮するには、export NINJA_PERSISTENT_MODE=1 を実行します。

Fuchsia ターゲットサポート

Fuchsia ターゲットサポートの詳細については、the rustc book の Fuchsia の章を参照してください。

2024 年 6 月時点で、Fuchsia には約 200 万行のファーストパーティ Rust コードと、ほぼ同量のサードパーティコードがありました。これは tokei によるカウントです（コメントと空行は除外）。 ↩

Rust Compiler Development Guide