Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

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

自動化とオープンソースのベスト プラクティスを活用して、アクションを解放および維持できます。

注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

はじめに

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

  • 継続的インテグレーション、依存関係の更新、リリース管理、タスクの自動化に 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 を最新の状態に保つ。

参考資料

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