アクションのリリースと管理

はじめに

アクションを作成した後、コミュニティ投稿を操作しながら、引き続き新機能をリリースする必要があります。 このチュートリアルでは、オープン ソースでアクションをリリースおよび管理するために従うことができるプロセスの例について説明します。 この例では、次の処理を実行します。

• 継続的インテグレーション、依存関係の更新、リリース管理、タスクの自動化に GitHub Actions を活用する。
• 自動テストとビルド バッジにより信頼度を提供する。
• 理想的にはより広範なワークフローの一部として、アクションを使用する方法を示す。
• 歓迎するコミュニティ投稿の種類を伝える (issue、pull request、脆弱性レポートなど)。

このプロセスの適用例については、「actions/javascript-action」をご覧ください。

アクションの開発とリリース

このセクションでは、アクションを開発およびリリースするプロセスの例について説明し、GitHub Actions を使用してプロセスを自動化する方法を示します。

JavaScript アクションについて

JavaScript アクションは、メタデータを含む Node.js リポジトリです。 しかし、JavaScript アクションには、従来の Node.js プロジェクトと比較して追加のプロパティがあります。

• 依存パッケージは、通常、コンパイルおよび縮小された形式でコードと共にコミットされます。 これは、自動ビルドとセキュリティで保護されたコミュニティ投稿が重要であることを意味します。

• 多くのアクションでは、GitHub の API とサード パーティの API が利用されるため、堅牢なエンドツーエンドのテストをお勧めします。

GitHub Actions ワークフローの設定

次のセクションで開発者プロセスをサポートするには、2 つの GitHub Actions ワークフローをリポジトリに追加します。

1. コミットが機能ブランチまたは main にプッシュされたとき、あるいは pull request が作成されたときにトリガーされるワークフローを追加します。 単体および統合テストを実行するようにワークフローを構成します。 例については、こちらのワークフローをご覧ください。
2. リリースが公開または編集されたときにトリガーされるワークフローを追加します。 セマンティック タグが確実に配置されるようにワークフローを構成します。 JasonEtco/build-and-tag-action などのアクションを使用して、JavaScript とメタデータ ファイルをコンパイルしてバンドルし、セマンティック メジャー、マイナー、およびパッチ タグを強制的にプッシュできます。 セマンティック タグの詳細については、「セマンティック バージョン管理について」を参照してください。

開発者プロセスの例

自動的にテストを実行し、リリース に公開して、アクションを公開するプロセスの例を以下に示します。

1. GitHub フローごとにブランチで機能作業を行います。 詳しくは、「GitHub フロー」を参照してください。

   • コミットが機能ブランチにプッシュされるたびに、テスト ワークフローではテストが自動的に実行されます。

2. main ブランチへの pull request を作成してディスカッションとレビューを開始し、準備ができたらマージします。

   • ブランチまたはフォークから pull request が開かれると、テスト ワークフローでは今度はマージ コミットで再びテストが実行されます。

   • 注: セキュリティ上の理由により、フォークから pull_request によってトリガーされるワークフローでは GITHUB_TOKEN アクセス許可が制限されており、シークレットにアクセスすることはできません。 pull request 時にトリガーされたテストまたはその他のワークフローでシークレットへのアクセスが必要な場合は、手動トリガーや pull_request_target などの別のイベントを使用することを検討してください。 詳しくは、「ワークフローをトリガーするイベント」を参照してください。

3. セマンティックにタグ付けされたリリースを作成します。 詳しくは、「リポジトリのリリースを管理する」を参照してください。

   • リリースが公開または編集されると、リリース ワークフローでコンパイルとタグの調整が自動的に行われます。

   • セマンティックにバージョン管理されたタグ (たとえば、v1.1.3) を使用してリリースを作成し、最新の適切なコミットに合わせてメジャー (v1) およびマイナー (v1.1) タグを最新の状態に保つことをお勧めします。 詳しくは、「カスタム アクションについて」および「セマンティック バージョン管理について」を参照してください。

結果

他のいくつかの自動リリース管理戦略とは異なり、このプロセスでは意図的に main ブランチではなく、タグ付けされたリリース コミットへの依存関係のみをコミットします。 これにより、アクションのユーザーに名前付きタグまたは sha を参照するよう促し、リリース時にビルドを自分で行うことで、サード パーティの pull request のセキュリティを確保できるようにします。

セマンティック リリースを使用すると、アクションのユーザーがワークフローをバージョンにピン留めでき、快適レベルに応じて、最新の安定した非破壊的機能を引き続き受け取る可能性があることを認識できます。

コミュニティでの作業

GitHub Enterprise Server には、オープンソース コミュニティでの作業に役立つツールとガイドが用意されています。 ここでは、正常な双方向通信用に設定することをお勧めするいくつかのツールを示します。 コミュニティに次のように伝えることで、他のユーザーにアクションの使用、変更、および貢献を促します。

• 多くの使用例とガイダンスを含む README を維持する。 詳しくは、「READMEについて」を参照してください。
• README ファイルにワークフロー ステータス バッジを含める。 詳しくは、「ワークフロー状態バッジの追加」を参照してください。 また、追加できるその他のバッジについては、shields.io にアクセスしてください。
• action/stale などのアクションを活用して issue を最新の状態に維持。

参考資料

同様のパターンを使用する例を以下に示します。

• github/super-linter
• octokit/request-action
• actions/javascript-action