新規リリースの検証方法¶
はじめに¶
このドキュメントには、最終的に次の LLVM リリースとなるリリース候補のテストに関する情報が含まれています。実際のリリースの管理方法の詳細については、LLVM を公開する方法 を参照してください。
リリースプロセスの概要¶
リリースプロセスが開始されると、リリース マネージャーはボランティアを募集します。各ボランティアの役割は次のとおりです。
以前のリリースをテストおよびベンチマークする
各リリース候補をテストおよびベンチマークし、以前のリリースおよび候補と比較する
テストとベンチマーク中に見つかったすべてのリグレッションを特定、削減、および報告する
重大なバグが修正され、次のリリース候補にマージされていることを確認する
すべてのバグやリグレッションがリリースを阻止するものではなく、次の候補の前に修正すべきものと次のリリースまで待つことができるものは、ややグレーゾーンです。
それは以下に依存します。
バグの重大度、影響を受ける人数、リグレッションか既知のバグか。既知のバグは「サポートされていない機能」であり、最近実装されたバグは、無効にすることができます。
リリースの段階。重要度の低いバグは RC1 と RC2 の間で修正されるべきですが、終了間際にはそうではありません。
正確性またはパフォーマンスのリグレッションかどうか。パフォーマンスのリグレッションは、正確性よりも軽く扱われる傾向があります。
スクリプト¶
スクリプトは utils/release ディレクトリにあります。
test-release.sh¶
このスクリプトは、LLVM+Clang（+ compiler-rt、libcxx、libomp、clang-extra-tools などのほとんどのアドオン）を3つの段階でチェックアウト、構成、コンパイルし、最終段階をテストします。最終的なバイナリは Phase3/Releasei(+Asserts) ディレクトリにインストールされます。テストスイートやその他の外部テストには、このディレクトリを使用する必要があります。
特定のリリース候補でスクリプトを実行するには、次を実行します。
./test-release.sh \
-release 3.3 \
-rc 1 \
-no-64bit \
-test-asserts \
-no-compare-files
システムごとに異なるオプションが必要です。たとえば、x86_64 は明らかに -no-64bit を必要としませんが、32ビットシステムは必要です。そうでないとスクリプトは失敗します。
正しく設定することが重要なフラグは次のとおりです。
リリース前には、
-rc 1を-finalに変更する必要があります。RC2 では、-rc 2に変更します。以下同様です。リリース以外のテストでは、
-finalを-no-checkoutと組み合わせて使用できますが、finalディレクトリを手動で作成し、正しいソースディレクトリをfinal/llvm.srcにリンクする必要があります。リリース候補の場合、
-test-assertsが必要です。そうでないと、「Release+Asserts」ディレクトリが作成されません。これは、リリーステストとベンチマークに必要です。これには2倍の時間がかかります.最終候補では、Release ビルドのみが必要です。これが、パッケージ化する必要があるバイナリディレクトリです。
macOS では、スクリプトを実行する前に
MACOSX_DEPLOYMENT_TARGET=10.9をエクスポートする必要があります。
このスクリプトは、Clang+LLVM の3つのフェーズをそれぞれ2回（Release と Release+Asserts）ビルドするため、screen または nohup を使用して頭痛の種を避けましょう。時間がかかるからです。
--help オプションを使用して、すべてのオプションを表示し、ニーズに合わせて選択します。
findRegressions-nightly.py¶
TODO
テストスイート¶
テストスイートのセットアップ方法については、LNT クイックスタートガイド のリンクに従ってください。
テストに使用する必要があるバイナリ場所は、rcN/Phase3/Release+Asserts/llvmCore-REL-RC.install 内にあります。そのディレクトリを簡単な場所にリンクし、テストスイートを実行します。
正しいインストールディレクトリから ~/devel/llvm/install にリンクを作成したと仮定した場合の実行コマンドラインの例
./sandbox/bin/python sandbox/bin/lnt runtest \
nt \
-j4 \
--sandbox sandbox \
--test-suite ~/devel/llvm/test/test-suite \
--cc ~/devel/llvm/install/bin/clang \
--cxx ~/devel/llvm/install/bin/clang++
以前のリリースまたはリリース候補と比較して、新しいリグレッションがあってはなりません。テストスイートのすべてのバグを修正する必要はありません。すべてのアーキテクチャで常にパスするとは限らないためです。これは、直接比較に依存する結果チェックの性質によるものです。ほとんどの場合、障害は、コード生成が悪いのではなく、出力チェックが悪いことに関連しています。
エラーが LLVM 自体にある場合は、見つかったすべてのリグレッションをブロッカーとして報告し、その他のすべてのバグは重要として報告してください。ただし、リリースの続行を必ずしもブロックする必要はありません。「既知の障害」として設定し、将来の日付に修正することができます.
リリース前プロセス¶
メーリングリストでリリースプロセスが発表されたら、リリース候補で行うのと同じテストを以前のリリースに適用して、テストの準備をする必要があります。
以下を行う必要があります。
以前のリリースのソースを https://llvm.dokyumento.jp/releases/download.html からダウンロードします。
test-release.sh スクリプトを
finalモードで実行します（-rc 1を-finalに変更します）。3つのステージがすべて完了すると、最終ステージがテストされます。
Phase3/Release+Asserts/llvmCore-MAJ.MIN-final.installベースを使用して、テストスイートを実行します。
最終フェーズの make check-all が失敗した場合は、obj ディレクトリに移動して make check-all を実行して、パスするステージが少なくとも1つあるかどうかを確認することをお勧めします（バグ報告の目的でエラーを削減するのに役立ちます）。
リリースプロセス¶
リリース マネージャーからリリース候補が送信されたら、すべてのソースをダウンロードし、同じディレクトリに解凍します（適切な場所からシンボリックリンクが作成されます）。上記のようにリリーステストを実行します。
以下を行う必要があります。
リリース マネージャーが指示する場所から現在の候補ソースをダウンロードします（例：https://llvm.dokyumento.jp/pre-releases/3.3/rc1/）。
-rc 1、-rc 2などのモードで上記の手順を繰り返し、同じ方法でテストスイートを実行します。結果を比較し、すべてのエラーを Bugzilla に報告し、リリース マネージャーが取得できる場所にバイナリブロブを公開します。
リリース マネージャーが最新の候補が適切であると発表したら、Phase3 の Release（Asserts なし）インストールディレクトリをパッケージ化する必要があります。これが公式バイナリになります。
clang+llvm-REL-ARCH-ENVの名前を .install ディレクトリに変更する（またはリンクする）ディレクトリの外側から
.tar.gz拡張子を使用して、同じ名前で tar にアーカイブするリリース マネージャーがダウンロードできるようにする
バグ報告プロセス¶
リリース候補を以前のリリースと比較したときにリグレッションまたは障害が見つかった場合は、以下のルールに従ってください。
コンパイル時の重大なバグは、できるだけ早く、できればバイナリブロブをリリースする前に修正する必要があります。
check-all テストは、次のリリース候補の前に修正する必要がありますが、テストスイートの実行が完了するまで待つことができます。
テストスイートのバグまたは重要でない check-all テストは、リリース候補の合間に修正できます。
リリース直前の新機能や最近の大きな変更は、簡単に無効にできる方法で行う必要があります。誤動作する場合は、不安定な（ただしテストされていない）バイナリパッケージをリリースするよりも、無効にすることをお勧めします。