[49162]の時点で、Coreは、既存のTravis CIおよびAppveyorの実行に加えて、GitHubアクションをランナーとして使用して自動テストを実行しています。この投稿は、変更を公表し、理由を文書化し、次のステップを伝え、WordPressCoreに貢献する人々がどのように利益を得るかを共有することです。
GitHubアクションを使用すると、GitHubイベントによってトリガーされ、GitHubで直接ソフトウェアワークフローを自動化できます。切り替えることで、統一されたインターフェース、プルリクエストでのリンティングの問題に対するインラインアノテーション、より広範なオープンソースエコシステムの構築とグーテンベルクでの既存の作業を含むアクションの使用、およびパブリックリポジトリの無料利用を利用できます。プライベートリポジトリは、含まれている分の月次バケットを使用することに注意してください。
寄稿者の場合、これにより、 GitHubプルリクエストを使用してTracチケットで作業するエクスペリエンスが引き続き改善されます。特に、PRの差分ビュー（注釈と呼ばれます）にリンティングエラーがインラインで表示されます。これにより、外部ツールも1か所に統合されます。まだ行っていない場合は、GitHubアカウントをWordPress.orgプロファイルに関連付けてください。
これらの6つのワークフローは、TravisCIおよびAppveyorで実行されている現在のすべてのテストと分析をカバーしています。
- PHPとJSのコーディング標準をチェックします。
- エンドツーエンドのテストスイートの実行。
- JavaScriptファイルでQUnitテストを実行します。
- サポートされているバージョンとのPHP互換性の問題をスキャンしています。
- PHPUnitテストスイートの実行。
- NPM関連のタスクを確認しても、Windowsでエラーは発生しません。
寄稿者の最初のプルリクエスト時にウェルカムメッセージを残すことを目的とした追加の7番目のワークフローもあり、GitHubプルリクエストの使用方法とTracチケットへのリンク方法を知らせます。フォークからPRを送信する場合の許可に問題があるようですので、保留中です。
現在、Travis CIとAppveyorは、問題を解決し、実際の使用状況データを収集できるように、移行期間（TBD終了）の間継続して実行されます。これまでのところ、初期のテストでも、たとえばTravis CIがミラーでコミットをまだ認識していない場合など、実行はより迅速に完了し、フォールスネガティブが少ないかまったくないように見えます。 @ desrosjは、スプレッドシート内の実行データを照合します。これには、全体的なビルド時間、実行時間の比較（1：1の比較が可能）、フォールスネガティブの頻度が含まれますが、これらに限定されません。
既知の次のステップ
- Slack通知を追加して構成します。コアコミットのビルド全体の結果を＃コアに送信することに加えて、PR用のファイアホースチャネルを検討することもできます。
- ビルドステータスインジケーターのGitHubバッジに移動します。これらはワークフローごとであり、特定のコミットのTravisビルド全体の単一のバッジとは異なることに注意してください。ただし、GitHubはコミット/ PRの全体的なステータスを報告するため、その情報も使用できる場合があります。
- テスト結果を[ホストテスト結果]ページに報告します。
- JSHintからESLintに切り替えます。後者はインラインアノテーションを簡単にサポートしていないようであり、前者はドキュメントのコア、グーテンベルク、および多くのコミュニティプロジェクトを含む幅広い用途に使用されています。詳細については、 ＃31823を参照してください–ボランティアはここで非常に高く評価されています。
- ワークフローファイルをアクティブに維持されている古いブランチにバックポートします。
いつものように、GitHubアクションで発生している問題と、使用するためのその他のアイデアを報告してください。主なおかげdesrosj @彼は数週間だけのカップルで行うのすべての重い物を持ち上げるための、およびへ@ ocean90と@ ayeshrajans道に沿って彼らの助けのため。
コメントを残す