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

はじめに

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

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

このプロセスの適用例については、github-developer/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 にアクセスしてく� さい。
• actions/stale などのアクションを利用して、issue を最新の状態に保つ。

参考資料

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

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