ノート: GitHub Actionsは、GitHub Enterprise Server 2.22で限定ベータとして利用可能でした。 ベータは終了しました。 GitHub Actionsは、GitHub Enterprise Server 3.0以降で一般に利用可能になりました。 詳しい情報については、GitHub Enterprise Server 3.0 のリリースノートを参照してください。
- GitHub Enterprise Server 3.0以降へのアップグレードに関する詳しい情報については「GitHub Enterprise Serverのアップグレード」を参照してください。
- アップグレード後のGitHub Actionsの設定に関する詳しい情報については、GitHub Enterprise Server 3.0のドキュメンテーションを参照してください。
ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情報を見ることができます。
はじめに
Azure PipelinesとGitHub Actionsは、どちらも自動的にコードのビルド、テスト、公開、リリース、デプロイを行うワークフローを作成できます。 Azure PipelinesとGitHub Actionsは、ワークフローの設定において似ているところがあります。
- ワークフローの設定ファイルはYAMLで書かれ、コードのリポジトリに保存されます。
- ワークフローには1つ以上のジョブが含まれます。
- ジョブには1つ以上のステップもしくは個別のコマンドが含まれます。
- ステップもしくはタスクは、再利用とコミュニティとの共有が可能です。
詳しい情報については、「GitHub Actionsの中核的概念」を参照してください。
主要な差異
Azure Pipelinesから移行する際には、以下の差異を考慮してください。
- Azure Pipelineはレガシーのクラシックエディタをサポートしています。これはCIの設定を、YAMLファイルでパイプラインの定義を作成する代わりに、GUIのエディタで定義できるようにするものです。 GitHub Actionsはワークフローの定義にYAMLファイルを使い、グラフィカルなエディタはサポートしていません。
- Azure Pipelinesでは、ジョブの定義中の一部の構造を省略できます。 たとえば、ジョブが1つだけしかないなら、ジョブを定義する必要はなく、ステップだけを定義すれば済みます。 GitHub Actionsは明示的な設定が必要であり、YAMLの構造は省略できません。
- Azure PipelinesはYAMLファイル中で定義されるステージをサポートしています。ステージは、デプロイメントのワークフローの作成に利用できます。 GitHub Actionsでは、ステージは個別のYAMLワークフローファイルに分割しなければなりません。
- オンプレミスのAzure Pipelinesビルドエージェントは、機能で選択できます。 GitHub Actionsのセルフホストランナーは、ラベルで選択できます。
ジョブとステップの移行
Azure Pipelinesのジョブとステップは、GitHub Actionsのジョブとステップによく似ています。 どちらのシステムでも、ジョブは以下の特徴を持ちます。
- ジョブは、順番に実行される一連のステップを持ちます。
- ジョブは、個別の仮想マシンまたは個別のコンテナで実行されます。
- ジョブは、デフォルトでは並列に実行されますが、順次実行するように設定することもできます。
スクリプトのステップの移行
スクリプトやシェルのコマンドを、ワークフロー中のステップとして実行できます。 Azure Pipelinesでは、スクリプトのステップはscript
キー、あるいはbash
、powershell
、pwsh
といったキーで指定できます。 スクリプトはまた、BashタスクあるいはPowerShellタスクへの入力としても指定できます。
GitHub Actionsでは、すべてのスクリプトはrun
キーを使って指定されます。 特定のシェルを選択するには、スクリプトを提供する際にshell
キーを指定します。 詳細については、「GitHub Actionsのワークフロー構文」を参照してください。
以下が、それぞれのシステムの構文の例です。
Azure Pipelines | GitHub Actions |
---|---|
|
|
スクリプトのエラー処理の差異
Azure Pipelinesでは、stderr
への出力があればスクリプトがエラーとなるように設定できます。 GitHub Actionsはこの設定をサポートしていません。
GitHub Actionsは、可能な場合にはシェルを"fail fast"に設定します。これは、スクリプト中のコマンドの1つがエラーコードで終了した場合に即座にスクリプトを停止させるものです。 これに対し、Azure Pipelinesではエラーの際に即座に終了させるためには、明示的に設定しなければなりません。 詳細については、「GitHub Actionsのワークフロー構文」を参照してください。
Windows上でのデフォルトシェルの差異
Azure Pipelinesでは、Windowsプラットフォーム上のスクリプトのためのデフォルトシェルはコマンドシェル(cmd.exe)です。 GitHub Actionsでは、Windowsプラットフォーム上のスクリプトのためのデフォルトシェルはPowerShellです。 PowerShellは、組み込みコマンド、変数の展開、フロー制御で多少の差異があります。
シンプルなコマンドを実行するなら、コマンドシェルのスクリプトを変更なしにPowerShellで実行できるかもしれません。 しかしほとんどの場合は、PowerShellの構文でスクリプトをアップデートするか、GitHub Actionsに対してスクリプトをPowerShellではなくコマンドシェルで実行するように指定することになります。 それには、shell
をcmd
と指定します。
以下が、それぞれのシステムの構文の例です。
Azure Pipelines | GitHub Actions |
---|---|
|
|
詳しい情報については、「GitHub Actions のワークフロー構文」を参照してください。
条件と式の構文の移行
Azure PipelinesとGitHub Actionsは、どちらもステップを条件付きで実行できます。 Azure Pipelinesでは、条件式はcondition
キーを使って指定します。 GitHub Actionsでは、条件式はif
キーを使って指定します。
Azure Pipelinesは、ステップを条件付きで実行するために、式の中で関数を使います。 それに対し、GitHub Actionsはinfix表記を使います。 たとえば、Azure Pipelinesにおけるeq
関数は、GitHub Actionsでは==
演算子に置き換えなければなりません。
以下が、それぞれのシステムの構文の例です。
Azure Pipelines | GitHub Actions |
---|---|
|
|
For more information, see "Expressions."
ジョブ間の依存関係
Azure PipelinesとGitHub Actionsは、どちらもジョブの依存関係を設定できます。 どちらのシステムでも、デフォルトではジョブは並行に実行されますが、ジョブの依存関係を明示的に指定できます。 Azure Pipelinesでは、これはdependsOn
キーで行います。 GitHub Actionsでは、needs
キーを使って行います。
以下は、それぞれのシステムにおける構文の例です。 このワークフローは、initial
という名前の最初のジョブを開始し、そのジョブが終わるとfanout1
とfanout2
という名前の2つのジョブが実行されます。 最後に、それらのジョブが完了すると、fanin
というジョブが実行されます。
Azure Pipelines | GitHub Actions |
---|---|
|
|
詳細については、「GitHub Actionsのワークフロー構文」を参照してください。
タスクのアクションへの移行
Azure Pipelinesはタスクを使います。これは、複数のワークフローで再利用できるアプリケーションのコンポーネントです。 GitHub Actionsはアクションを使います。これは、タスクの実行とワークフローのカスタマイズに利用できます。 どちらのシステムでも、実行するタスクやアクションの名前を、必要な入力のキー/値のペアとともに指定できます。
以下が、それぞれのシステムの構文の例です。
Azure Pipelines | GitHub Actions |
---|---|
|
|
ワークフロー中で利用できるアクションは、GitHub Marketplaceで見つけることも、独自のactionsを作成することもできます。 詳細については、「アクションを作成する」を参照してください。