非公式プラグインのCIワークフローはどのように実装できますか？

開発
1

コミュニティ提供の非公式プラグインでテストを実行する、CIワークフローの可能性について、ご意見をお聞かせください。

多くのコミュニティは、確立されたメンテナンスのないプラグインに大きく依存しています。

プラグインのテストはDiscourseのインストールをテストベッドとして必要とするため、コミュニティがサポートするCIワークフローはどのようなものになるのか疑問に思っています。

一部のプラグインには、@angusによるactivitypubの実装のように仕様が含まれており、私の理解では、CIのテストを可能にします。

現在、プラグインソースに含まれる仕様/テストに応じて、非公式プラグインのテストを改善するための2つの可能な方法を考えています。

a) テスト環境でテストを実行するサイトメンテナーを支援する仕組みを構築する

b) プラグインの最後の公開コードで実行されたテストを報告するために、定義済みのテストイメージをフォークするサービスを提供する。

どう思われますか？

すでに確立されたワークフローを見逃していませんか？

2

これは役立つかもしれません。

「いいね！」 3
3

バックエンドとフロントエンドのテストを含むCIに加えて、ほとんどのPavilionプラグインが現在持っているものとして、CIがその一部であるプラグインマネージャーシステムがあります。仕組みは次のとおりです。

image
image690×459 33.5 KB

「いいね！」 3
4

はい、@angus が共有した内容に加えて、日次の互換性ダッシュボードは以下で見つけることができます。

https://coop.pavilion.tech/plugins?branch=tests-passed

これは、Pavilion プラグイン（およびその他のプラグイン）の tests-passed および stable に対する互換性のチェック状況を表示します。これは毎日自動的に更新されます。

もちろん、これにはスモークテスト、スペック（バックエンド）、qunit（フロントエンド）テストを含むテストが依存しています。

サブスクリプションプラグイン（Custom Wizard）は、想像どおり、最もテストカバレッジがありますが、無料プラグインの中には、バックエンドとフロントエンドの両方のテストの良いスイートが含まれているものもあります（例：Locations）。

テストの記述は良い習慣であり、ビジネスとして成熟するにつれて、Pavilion はこの分野でさらに規律を強めてきました。

決定的に、テストは意図した機能も文書化します。これは、互換性アップデートやリファクタリング中に特に重要です。

「いいね！」 2
5

素晴らしいですね。これを実装しているコードを教えていただけますか？

「いいね！」 1
6

@angus の図に基づいたアーキテクチャで、複数のリポジトリが関与していますが、これはステータスサーバーです。

これはアプローチでもあります。

  • テストを確認せずに修正を実装することは決してなく、適切なテストが存在しない場合は追加します。
  • できれば、まずテストを開発し、それが失敗することを示してから、問題を修正し、新しいテストがパスすることを確認します。

そうすれば、カバレッジは時間とともに構築されます…

さらに：

  • テストの後付けは、コードが意図していたことを誤解する可能性があるため危険な場合があります… 何もしないよりはましですが…
「いいね！」 1
7

すべての公式プラグインには、例として使用できる仕様があります。discourse-plugin-Skelton プラグインには、コミットごと、そして毎日（だと思います）テストを実行するための GitHub Actions が含まれています。

「いいね！」 2
8

理解は正しいでしょうか？

a) これはGitHubアクションで利用できます：適切な仕様/テストを備えたプラグインは、GitHubアクションを使用して、GitHubにバッジが表示され、すべてのテストに合格し、CIアクションのステータスがAPIで読み取れるようになります。

b) Discourseの公式プラグインとPavilionプラグインを除き、管理者向けの自動概要は存在しません。使用中のプラグインが更新対象のバージョンで機能するかどうかは？

プラグインの互換性に関するメタデータを検索したところ、.discourse-compatibility ファイルを介して Introducing .discourse-compatibility: pinned plugin/theme versions for older Discourse versions を見つけました。

これは逆の問題、つまり「Discourseが古すぎてプラグインが使えない」に対する解決策だと理解しています。
「プラグインが古すぎてDiscourseで使えない」という逆の場合はどうすればよいでしょうか？

/admin/upgrade は、更新対象のプラグインでテストが失敗した場合に警告を発することはできますか？

9

当初、サードパーティの作成者がプラグインを提出できる、ブランド名のないプラグインダッシュボードを提供する予定でした。しかし、サードパーティのプラグイン開発者の数が非常に少ないため、これはあまり普及しませんでした。

サードパーティのDiscourseプラグイン開発は非常にニッチであり、十分なテストカバレッジを持つプラグインを提供するサードパーティは非常にニッチです！ :sweat_smile:

この分野のフリーランサーの多くは、PavilionまたはCDCK（あるいは、時間とともに両方！）に参加しています。

そのため、最終的にダッシュボードをブランドコミュニティサイトに統合することにしました。

「いいね！」 2