👋 We've unified all of GitHub's product documentation in one place! Check out the content for REST API, GraphQL API, and Developers. Stay tuned for a blog post later today.


ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

アクションについて

アクションは個々のタスクで、組み合わせてジョブを作成したりワークフローをカスタマイズしたりできます。 You can create your own actions, or use and customize actions shared by the GitHub community.

GitHub ActionsはGitHub Free、GitHub Pro、GitHub FreeのOrganization、GitHub Team、GitHub Enterprise Cloud、GitHub Oneで利用できます。 GitHub Actionsは、レガシーのリポジトリごとのプランを使っているアカウントが所有しているプライベートリポジトリでは利用できません。 詳しい情報については「GitHubの製品」を参照してください。

ここには以下の内容があります:

探していたものは見つけられましたか?

アクションについて

GitHubの API やパブリックに利用可能なサードパーティAPIとのインテグレーションなど、好きな方法でリポジトリを操作するカスタムコードを書いて、アクションを作成することができます。 たとえば、アクションでnpmモジュールを公開する、緊急の問題が発生したときにSMSアラートを送信する、本番対応のコードをデプロイすることなどが可能です。

ワークフローで使用する独自のアクションを作成したり、ビルドしたアクションをGitHubコミュニティと共有したりできます。 ビルドしたアクションをシェアするには、リポジトリをパブリックにする必要があります。

アクションはマシン上で直接実行することも、Dockerコンテナで実行することもできます。 アクションの入力、出力、環境変数を定義できます。

アクションの種類

DockerコンテナのアクションとJavaScriptのアクションをビルドできます。 アクションには、アクションの入力、出力、およびメインのエントリポイントを定義するメタデータファイルが必要です。 このメタデータのファイル名はaction.ymlもしくはaction.yamlでなければなりません。 詳しい情報については、「GitHub Actions のメタデータ構文」を参照してください。

種類オペレーティングシステム
DockerコンテナLinux
JavaScriptLinux、MacOS、Windows

Dockerコンテナのアクション

Dockerコンテナは、GitHub Actionsコードで環境をパッケージ化します。 アクションの利用者がツールや依存関係を考慮しなくて済むため、作業単位の一貫性と信頼性が向上します。

Dockerコンテナを使用すると、Osのバージョン、依存関係、ツール、コードを限定することができます。 特定の環境設定で実行しなければならないアクションの場合、オペレーティングシステムとツールを選択できるので、Dockerは理想的な選択肢です。 コンテナのビルドおよび取得のレイテンシにより、DockerコンテナのアクションはJavaScriptアクションより遅くなります。

Docker container actions can only execute on runners with a Linux operating system. セルフホストランナーでDockerコンテナアクションを実行するためには、Linuxオペレーティングシステムを使い、Dockerがインストールされていなければなりません。 セルフホストランナーに対する要求に関する詳しい情報については「セルフホストランナーについて」を参照してください。

JavaScriptのアクション

JavaScriptアクションはランナーマシン上で直接実行でき、アクションのコードはそのコードを実行するのに使われた環境から分離できます。 JavaScriptのアクションを使うと、アクションコードが単純になり、実行も Dockerコンテナのアクションより速くなります。

JavaScriptのアクションがGitHubがホストするすべてのランナー(Ubuntu、Windows、macOS)と互換性があることを保証するためには、作成するパッケージ化されたJacScriptのコードは純粋なJavaScriptであり、他のバイナリに依存していてはなりません。 JavaScriptのアクションはランナー上で直接実行され、仮想環境内にすでに存在するバイナリを利用します。

セルフホストランナーでJavaScriptアクションを実行するためには、Node.jsがインストールされていなければなりません。 セルフホストランナーに対する要求に関する詳しい情報については「セルフホストランナーについて」を参照してください。

Node.jsプロジェクトの開発では、GitHub Actions Toolkitで提供するパッケージを使って、開発の速度を上げることができます。 詳しい情報については、actions/toolkit リポジトリ以下を参照してください。

アクションの場所を選択する

他のユーザーが使うアクションを開発する場合には、他のアプリケーションコードにバンドルするのではなく、アクションをそれ自体のリポジトリに保持しておくことをお勧めします。 こうすると、他のソフトウェアと同様にアクションのバージョニング、追跡、リリースが可能になるからです。

アクションをそれ自体のリポジトリに保存すると、GitHubコミュニティがアクションを見つけやすくなります。また、開発者がアクションの問題を解決したり機能を拡張したりするとき、コードベースのスコープが限定され、アクションのバージョニングが他のアプリケーションコードのバージョニングから切り離されます。

ビルドしているアクションをパブリックに公開する予定がない場合、アクションのファイルはリポジトリのどの場所に保存してもかまいません。 アクション、ワークフロー、アプリケーションコードを 1 つのリポジトリで組み合わせる予定の場合、アクションは .github ディレクトリに保存することをお勧めします。 たとえば、.github/actions/action-a.github/actions/action-bに保存します。

Using release management for actions

This section explains how you can use release management to distribute updates to your actions in a predictable way.

Good practices for release management

If you're developing an action for other people to use, we recommend using release management to control how you distribute updates. Users can expect an action's major version to include necessary critical fixes and security patches, while still remaining compatible with their existing workflows. You should consider releasing a new major version whenever your changes affect compatibility.

Under this release management approach, users should not be referencing an action's master branch, as it's likely to contain the latest code and consequently might be unstable. Instead, you can recommend that your users specify a major version when using your action, and only direct them to a more specific version if they encounter issues.

To use a specific action version, users can configure their GitHub Actions workflow to target a tag, a commit's SHA, or a branch named for a release.

Using tags for release management

We recommend using tags for actions release management. Using this approach, your users can easily distinguish between major and minor versions:

  • Create and validate a release on a release branch (such as release/v1) before creating the release tag (for example, v1.0.2).
  • Create a release using semantic versioning. 詳細は「リリースを作成する」を参照してください。
  • Move the major version tag (such as v1, v2) to point to the Git ref of the current release. 詳細については、「Gitの基本 - タグ」を参照してください。
  • Introduce a new major version tag (v2) for changes that will break existing workflows. たとえば、アクションの入力の変更は破壊的変更です。
  • Major versions can be initially released with a beta tag to indicate their status, for example, v2-beta. The -beta tag can then be removed when ready.

This example demonstrates how a user can reference a major release tag:

steps:
    - uses: actions/javascript-action@v1

This example demonstrates how a user can reference a specific patch release tag:

steps:
    - uses: actions/javascript-action@v1.0.1

Using branches for release management

If you prefer to use branch names for release management, this example demonstrates how to reference a named branch:

steps:
    - uses: actions/javascript-action@v1-beta

Using a commit's SHA for release management

Each Git commit receives a calculated SHA value, which is unique and immutable. Your action's users might prefer to rely on a commit's SHA value, as this approach can be more reliable than specifying a tag, which could be deleted or moved. However, this means that users will not receive further updates made to the action. Using a commit's full SHA value instead of the abbreviated value can help prevent people from using a malicious commit that uses the same abbreviation.

steps:
    - uses: actions/javascript-action@172239021f7ba04fe7327647b213799853a9eb89

アクションのREADMEファイルを作成する

アクションをパブリックに共有する予定がある場合には、アクションの使用方法を伝えるため README ファイルを作成することをお勧めします。 README.md には、以下の情報を含めることができます:

  • アクションが実行する内容の説明
  • 必須の入力引数と出力引数
  • オプションの入力引数と出力引数
  • アクションが使用するシークレット
  • アクションが使用する環境変数
  • ワークフローにおけるアクションの使用例

GitHub Appsに対するGitHub Actionsの比較

GitHub Marketplaceは、ワークフローを改善するツールを提供します。 それぞれのツールの違いや利点を理解すれば、自分の作業に最も適したツールを選択できるようになります。 For more information about building actions and apps, see "About GitHub Actions" and "About apps."

GitHub ActionsとGitHub Appsの強み

GitHub ActionsとGitHub Appはどちらもビルドの自動化の方法とワークフローツールを提供しますが、これらはそれぞれ異なる強みを持っており、違ったやり方で役立ちます。

GitHub Appsは:

  • 永続的に動作し、イベントに素早く反応できます。
  • 永続化されたデータが必要な場合にうまく動作します。
  • 時間のかからないAPIリクエストとうまく働きます。
  • ユーザが提供するサーバーあるいはコンピューティングインフラストラクチャ上で動作します。

GitHub Actionsは:

  • 継続的インテグレーションや継続的デプロイメントを実行する自動化を提供します。
  • ランナーマシン上でもDockerコンテナ内でも直接実行できます。
  • リポジトリのクローンへのアクセスを含めて、コードにアクセスするツール、コードフォーマッタ、コマンドラインツールをデプロイしたり公開したりできます。
  • コードのデプロイやアプリケーションの提供が必要ありません。
  • シークレットの生成と利用のためのシンプルなインターフェースを持っており、アクションを利用する人の認証情報を保存せずにサードパーティのサービスとアクションを連携できます。

参考リンク

探していたものは見つけられましたか?

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください