GitHub Actions構成

シークレット、ワークフロー、制限など、 GitHub Actionsに関する構成情報。

のシークレット GitHub Actions

リポジトリまたはGitHub組織GitHubシークレット (認証情報) を作成します。シークレットは、Organization またはリポジトリで作成する環境変数 (暗号化) です。これらのシークレットは、 GitHub Actions ワークフローで使用できます。詳細については、「 暗号化されたシークレット」を参照してください。

シークレット	説明
SN_INSTANCE_URL	ServiceNowインスタンスの URL です。例:https://<instance_name>.service-now.com。
SN_ORCHESTRATION_TOOL_ID	ServiceNowインスタンスで作成されたGitHubツールのSys_id。
SN_DEVOPS_INTEGRATION_TOKEN	DevOps で作成された GitHub ツールのシークレットトークン (devops-integration-token パラメーター)。シークレットトークンにアクセスするには、ServiceNow ([すべての>ツール] > オーケストレーションツール) でGitHubツールレコードに移動し、クラシック UI で [トークンのコピー] を選択します。

GitHubリポジトリ内のワークフロー

YAML ファイルを作成して、 GitHub リポジトリでワークフロー構成を定義します。

ワークフローを定義する際には、次の点を考慮する必要があります。

• リポジトリのすべてのワークフローには、.yml または .yaml ファイル拡張子が必要です。すべてのワークフローは .github/workflows ディレクトリにあり、 GitHub Actions のワークフロー構文で定義されている構文に従う必要があります。

  

• ワークフローの名前は、ワークフローファイル名と一致する必要があります。

  

• [アクション] タブの [すべてのワークフロー] の下にあるワークフローの名前は、リポジトリの .github/workflows ディレクトリに保存されているワークフローと一致する必要があります。

  

• 表示名はジョブごとに指定する必要があり、ワークフロー内のすべてのジョブで一意である必要があります。ジョブ名は、カスタムアクションのステージ名と一致する必要があります。

  

• workflow_dispatchイベントを使用して、ワークフローを手動でトリガーします。

  

GitHub Actions のワークフロー実行の詳細 DevOps

Webhook を設定すると、ワークフローが実行またはトリガーされるたびに、 GitHub Actions からの通知が ServiceNow DevOps に送信されます。

ワークフローが手動で実行されたとき、またはGitHubリポジトリで自動的にトリガーされたときに、次の詳細がServiceNowインスタンスに送信されます。

• workflow_job Webhook は、ワークフローが手動で実行されたとき、またはGitHubリポジトリで自動的にトリガーされたときに、ジョブのステータス (キューに格納、in_progress、完了) をServiceNowインスタンスに通知します。
• 受信イベントは、ジョブのステータス (キューに格納、in_progress、完了) の ServiceNow インスタンスに作成され、in_progressイベントは無視されます。
• キューに入れられた受信イベントと完了した受信イベントが処理され ServiceNow DevOps ワークフローで構成されたジョブのパイプラインステップとオーケストレーションタスクが作成されます。
• パイプライン実行は、ワークフロー実行で実行されたジョブごとに作成されたタスク実行およびステップ実行レコードを使用して、ワークフロー実行ごとに作成されます。
• パイプライン UI を使用して、パイプライン実行全体のインタラクションと結果を可視化できます。

GitHub 再実行

GitHubジョブに対して作成された変更要求は、変更要求が実装ステージおよび実装後ステージにある場合に再利用されます。たとえば、パイプライン実行の場合:

• 変更要求が実装ステージになる前にジョブが失敗した場合、失敗したジョブが再実行されたときに作成された変更要求は再利用されません。
• 失敗したジョブまたはすべてのジョブが再実行されると、新しい変更要求が作成されます。
• 変更要求が実装ステージまたは実装後ステージにあるときにジョブが失敗した場合、失敗したジョブまたはすべてのジョブが再実行されたときに変更要求が再利用されるようになりました。
  注:

  ジョブが失敗する前の前のステップで変更要求が既に実装されている場合、再実行中でもパイプラインの実行は停止されません。変更要求は既に承認され、実装されていると見なされます。

複合ワークフロー

あるワークフローが別のワークフローを呼び出し、変更ステップが子ワークフロー内にある複合ワークフローの場合、変更ステップの job-name パラメーターは、 job-name: '<親ジョブ名> / <子ジョブ名>'の形式にする必要があります。ここでは、スラッシュ (/) の前後のスペースは必須です。

図 : 1. 子ワークフローのジョブ名パラメーターの例

GitHub ActionsDevOps 変更速度 統合の制限事項

• GitHub Actions および GitHub 環境は、バージョン 3.3 以降の GitHub Enterprise Server でサポートされています。
  • GitHub環境の詳細については、「配置のための環境の使用」を参照してください。
  • GitHub 環境は、 GitHub Enterprise Cloud のプライベート リポジトリでのみ使用できます。
• GitHub組織の場合は、ServiceNow DevOpsと統合するために、個人アクセストークンを持つ特定のアカウント (必要な組織へのアクセス権を持つ) を使用するか、認証コード 2.0 または JWT を介して GitHub アプリを使用することもできます。

  GitHubアプリ - JWT を使用してツールを作成するには、別の組織に別のツールを作成する必要があります。

• ワークフロー実行のために、最新の GitHub Actions スキャン結果のみをインスタンスからプルできます。
• ServiceNow DevOps カスタムアクションまたは環境を使用した変更の自動化は、並列ジョブではサポートされていません。並列ジョブの場合、Webhook 通知ペイロードには、シーケンス番号とともに並列に実行されたジョブに関する情報は含まれません。この制限により、ジョブのシーケンスは (/repos/{owner}/{repo}/actions/runs/{run_id}/jobs) API の応答によって返される実行順序に依存します。
• ServiceNowインスタンスから実行されるワークフローを一時停止および再開するためのコールバック URL はGitHub Actions展開ゲート機能でのみサポートされています。ただし、デプロイゲートと GitHub カスタムアクションの両方を使用して変更を作成できます。
• ServiceNowインスタンスでGitHubツールを作成するユーザーは、GitHub 環境のワークフローを承認するレビュー担当者である必要があります。

関連タスク

• 手動で GitHub で Webhook を構成する