GitHub Actions構成

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

のシークレット GitHub Actions

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

シークレット	Description (説明)
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リポジトリのワークフロー

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

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

• リポジトリのすべてのワークフローには、ファイル拡張子が .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 ジョブに対して作成された変更要求が再利用されます。たとえば、パイプライン実行の場合:

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

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

複合ワークフロー

あるワークフローが別のワークフローを呼び出し、変更ステップが子ワークフローにある複合ワークフローの場合、変更ステップの<c0/>パラメータは、job-name: '<parent-workflow-name> / <child-workflow-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 Apps を使用することもできます。

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

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

関連タスク

• GitHub での Webhook の手動構成