GitHub Actions構成

  • リリースバージョン: Australia
  • 更新日 2026年04月20日
  • 所要時間：6分

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

    GitHub Actionsのシークレット

    GitHub リポジトリまたは GitHub 組織でシークレット (認証情報) を作成します。シークレットは、組織またはリポジトリで作成する環境変数 (暗号化) です。これらのシークレットは、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 で [トークンをコピー] を選択します。
    注:
    認証を確実に成功させるには、SN_DEVOPS_INTEGRATION_TOKENシークレットを新しいトークンで手動で更新する必要があります。

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

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

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

      [GitHub アクション (GitHub Actions)] タブのワークフロー

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

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

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

      [アクション] タブでのワークフローファイルの配置

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

      カスタムアクションのジョブ名

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

      イベントを使用したワークフローの手動トリガー

    DevOps における GitHub Actionsワークフロー実行の詳細

    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「<parent-job-name>/<child-job-name>」の形式である必要があります。ここでは、スラッシュ (/) の前後のスペースは必須です。

    図 : 1. 子ワークフローのジョブ名パラメーターの例
    サンプルの job-name パラメーター。

    DevOps 変更速度管理統合における GitHub Actionsの制限事項

    • 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 インスタンスで GitHub ツールを作成するユーザーは、GitHub 環境のワークフローを承認するレビュー担当者である必要があります。