MEP19: 継続的インテグレーション#

ステータス番号

完了

ブランチとプルリクエスト#

アブストラクト#

matplotlib は、インストーラーとドキュメントのテストとビルドの両方で、より優れた信頼性の高い継続的統合の恩恵を受けることができます。

詳細な説明#

現在の最先端#

テスト

matplotlib は現在、自動テストに Travis-CI を使用しています。Travis-CI は、無料サービスとして十分な機能を備えていることは称賛に値しますが、多くの欠点があります。

  • 依存関係をインストールするときのネットワーク タイムアウトが原因で失敗することがよくあります。

  • 不可解な理由で失敗することがよくあります。

  • ビルドまたはテスト製品は、プル リクエストではなく、メイン リポジトリのブランチのビルドからのみ保存できます。これは、後でローカルで障害を再現できない場合に特にイライラします。

  • 非常に高速ではありません。テストのための matplotlib の CPU およびメモリ要件は、平均的な Python プロジェクトよりもはるかに高くなります。

  • Ubuntu Linux でのみテストされ、プラットフォームの詳細については最小限の制御しかありません。これは、私たちの管理外でいつでもアップグレードできるため、リリース スケジュールに都合の悪い時期に予期しない遅延が発生する可能性があります。

プラス面として、Travis-CI の github との統合 (保留中のすべてのプル リクエストを自動的にテストする) は非常に優れています。

ビルド

matplotlib の自動バイナリ ビルドのための集中的な作業はありません。ただし、次のようなさまざまなことが行われています [ここで言及されている作成者が詳細を記入できれば、それは素晴らしいことです!]:

  • @sandrotosi: Debian パッケージをビルドします

  • @takluyver: Launchpad で自動化された Ubuntu ビルドがあります

  • @cgohlke: Windows ビルドを作成します (どの程度自動化されているかはわかりません)

  • @r-owen: OS-X ビルドを作成します (どの程度自動化されているかはわかりません)

ドキュメンテーション

main のドキュメントは現在、travis によって作成され、https: //matplotlib.org/devdocs/index.html にアップロードされています。

@NelleV はドキュメントを自動的に生成し、Web 上に投稿して MEP10 の進捗状況をグラフ化していると思います。

matplotlib の特徴#

matplotlib には複雑な要件があり、他の多くの Python プロジェクトよりもテストとビルドに負担がかかります。

  • テストを実行するための CPU 時間は非常に長くなります。これにより、多くの CI サービス (ShiningPanda など) の無料アカウントを超えることができます。

  • 多数の依存関係があり、すべての組み合わせの完全なマトリックスをテストすることは実際的ではありません。どのスペースをテストし、サポートすることを保証するかについては、賢くする必要があります。

要件#

このセクションでは、必要な要件の概要を説明します。

  1. Travis-CI が行うように、GitHub API にフックしてすべてのプル リクエストをテストする

  2. すべての主要なプラットフォームでのテスト: Linux、Mac OS-X、MS Windows (ユーザー調査に基づく優先順位の順)

  3. 事後分析のデバッグを支援するために、過去 n 日間分のビルドおよびテスト製品を保持します。

  4. 自動化されたナイトリー バイナリ ビルドにより、ユーザーは完全なコンパイル環境をインストールしなくても最前線をテストできます。

  5. 自動ベンチマーク。さまざまなバックエンドやプラットフォームで、パフォーマンスを経時的に追跡できる標準的なベンチマーク スイート (テストとは別) があると便利です。これはビルドとテストとは別のものですが、理想的には同じインフラストラクチャで実行されます。

  6. 自動化された毎晩のドキュメントの作成と発行 (またはテストの一環として、PR がドキュメントのバグを導入しないようにするため)。(これは、デフォルトとして安定版リリースの静的ドキュメントを置き換えるものではありません)。

  7. テスト システムは複数の開発者が管理できるようにして、1 人がボトルネックにならないようにする必要があります。(Travis-CI の設計はこれをうまく行っています。ビルド構成を他の場所ではなく git リポジトリに保存することは、非常に優れた設計です。)

  8. matplotlib の依存関係のさまざまなバージョンの大規模だがまばらなマトリックスを簡単にテストできるようにします。matplotlib ユーザー調査では、どこに注力すべきかについての良いデータが提供されています: https://docs.google.com/spreadsheets/d/1jbK0J4cIkyBNncnS-gP7pINSliNy9lI-N4JHwxlNSXE/edit

  9. あると便利: あまり知られていないプラットフォームを使用しているユーザーがビルド結果を中央のダッシュボードに発行できるようにするための分散型設計。

実装#

この部分はまだ書いていません。

ただし、理想的には、すでに引き伸ばされた時間にシステム管理を追加することを避けるために、実装はサードパーティ サービスになります。寄付された資金がいくつかあるため、このサービスが無料サービスよりも大幅な時間節約の利点を提供する場合、このサービスは有料サービスになる可能性があります.

下位互換性#

下位互換性は、この MEP にとって大きな問題ではありません。現在のツールと手順をより良いものに置き換え、古いものを捨てます。

代替案#

ハングアウト メモ#

CI インフラストラクチャ#

  • 私たちはトラビスが好きで、いずれにせよ、それはおそらく私たちの武器の一部であり続けるでしょう. 信頼性の問題は調査中です。

  • Travis でテスト製品の Amazon S3 アップロードを有効にします。これは、失敗の事後分析に役立ちます (@mdboom が現在調査中です)。

  • Mac のカバレッジが必要です。おそらく最善の策は、Travis に Pro アカウントの料金を支払って、プロジェクトで有効にするようにプッシュすることです (そうしないと、Linux と Mac の両方でのテストが許可されないため)。

  • Windows のカバレッジが必要です。シャイニングパンダはオプションです。

  • さまざまなソースからテスト結果を収集して合成し、GitHub API を使用して GitHub に投稿するツールの検索または構築について調査します。これは、Scipy コミュニティで一般的に使用される可能性があります。

  • Windows と Mac の両方について、ビルド用にマシンをセットアップするプロセスと、バイナリとインストーラーをビルドする方法を文書化 (できればスクリプト化) する必要があります。これには、Russel Owen と Christoph Gohlke からの情報が必要になる場合があります。これは、自動ビルドを行うために必要なステップですが、他の多くの理由からも価値があります。

テスト フレームワーク自体#

  • 時間を短縮する方法を検討する必要があります

    • 可能であれば、冗長なテストを排除する

    • matplotlib の一般的なパフォーマンスの向上が役立ちます

  • より多くのこと、特により多くのバックエンドをカバーする必要があります

  • 可能であれば、単体テストを増やし、統合テストを減らすべきです