Jenkins に接続する

Jenkins トリガーと Secure Source Manager Webhook を使用して、自動ビルドを開始できます。

必要なロール

Jenkins ビルドトリガーの作成に必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

必要な権限は、カスタム ロールや他の事前定義 ロールから取得することもできます。

Secure Source Manager ロールの付与については、 IAM によるアクセス制御ユーザーにインスタンスへのアクセス権を付与するをご覧ください。

Webhook トリガーを設定する

Jenkins は、ビルドトリガー プラグインを使用して CI/CD の自動化を有効にします。新しい commit がリポジトリに push されたときや、pull リクエストが開始されたときなどでの受信イベントをリッスンし、新しいイベントが生じたときにビルドを自動的に実行するようにトリガーを構成できます。ソース リポジトリが変更された場合や、特定の条件に一致する変更があった場合にコードをビルドするようにトリガーを構成することもできます。

汎用 Jenkins Webhook トリガーを設定するには:

  1. Jenkins サーバーに Jenkins Git PluginSSH Credential Plugin および Generic Webhook Trigger Plugin をインストールします。

  2. Jenkins サーバーで有効な SSH 認証鍵ペアを生成します。 Secure Source Manager は RSA タイプの鍵のみをサポートしています。

  3. 次のコマンドを実行して、Secure Source Manager インスタンス ドメインを Jenkins サーバー SSH known_hosts ファイルに追加します。

    ssh -t git@INSTANCE_ID-INSTANCE_PROJECT_NUMBER-ssh.us-central1.sourcemanager.dev
    

    ここで

    • INSTANCE_ID は、Secure Source Manager インスタンスの名前です。
    • INSTANCE_PROJECT_NUMBER は、 Secure Source Manager インスタンスのプロジェクト番号です。プロジェクト番号の確認方法については、 プロジェクトの識別 をご覧ください。

    たとえば、次のコマンドは、プロジェクト番号が 123456789prod-test-instance という名前のインスタンスのインスタンス ドメインを追加します。

    ssh -t git@prod-test-instance-123456789-ssh.us-central1.sourcemanager.dev
    

    yes と入力して、インスタンス ドメインを既知のホストのリストに追加します。

  4. Jenkins の [Manage Credentials] ページで、次の操作を行います。

    1. [SSH username with private key] を選択します。
    2. Jenkins サーバーの SSH 秘密鍵を貼り付けます。
    3. [Kind] プルダウンで、必要に応じて他のフィールドに入力します。
  5. [作成] をクリックします。

  6. Jenkins ウェブ インターフェースで、新しい Jenkins ジョブを作成します。

  7. Jenkins ジョブの構成ページの [Source Code Management] セクションで、[Git] を選択します。

  8. [Git] セクションで、Secure Source Manager リポジトリの SSH URL をリポジトリ URL として貼り付け、ビルド ブランチ(*/main など)を入力します。次に、[Manage Credentials] ページで以前に追加した保存済みの秘密 SSH 認証鍵の認証情報を選択します。

  9. [Build Triggers] セクションで、[Generic Webhook Trigger] を選択します。

    必要に応じて、呼び出し時にトークンが指定された場合にのみジョブがトリガーされるようにトークンを追加できます。トークンを追加するには、[Generic Webhook Trigger] セクションの [Token] フィールドにトークンを入力します。

  10. [Build] セクションで、この Jenkins ジョブに使用するビルド スクリプトを指定します。たとえば、cat README.md を実行して README.md の内容を出力できます。

  11. [保存] をクリックして Jenkins ジョブを作成します。

サービス アカウントを設定して必要な権限を付与する

  1. 使用するサービス アカウントがない場合は、 サービス アカウントを作成します

    サービス アカウントに対する iam.serviceAccounts.actAs 権限があることを確認します。この権限は、サービス アカウント ユーザー(roles/iam.serviceAccountUser)ロールの一部です。

  2. Secure Source Manager ウェブ インターフェースで、 [その他のオプション] メニューをクリックします。

  3. [サービス アカウントの SSH 認証鍵] をクリックします。[サービス アカウント SSH 認証鍵] ページが開き、追加した既存の鍵のリストが表示されます。

  4. [鍵を追加] をクリックします。

  5. [Add SSH key] ページで、鍵に次の値を入力します。

    1. サービス アカウント: SSH 認証鍵を使用するサービス アカウントのサービス アカウントのメールアドレス( SA_NAME@PROJECT_ID.iam.gserviceaccount.com

      場所

      • SA_NAME はサービス アカウント名です。
      • PROJECT_ID は、サービス アカウントが作成されたプロジェクトのプロジェクト ID です。
    2. SSH Public Key: Jenkins の公開 SSH 認証鍵。

Secure Source Manager サービス エージェントの権限を付与する

サービス アカウントが Secure Source Manager インスタンスと同じプロジェクトにない場合は、Secure Source Manager サービス エージェントにサービス アカウント トークン作成者(roles/iam.serviceAccountTokenCreator)ロールまたはiam.serviceAccounts.signJwt権限を付与する必要があります。

サービス アカウントが Secure Source Manager インスタンスと同じプロジェクトにある場合は、 サービス アカウントにリポジトリ ロールを付与するに進みます。

  1. 次のコマンドを実行して、サービス アカウントの既存の IAM ポリシーを取得します。

    gcloud iam service-accounts get-iam-policy SERVICE_ACCOUNT \
        --format json
    

    ここで、SERVICE_ACCOUNT は使用するサービス アカウントです。 アカウントは、数値のサービス アカウント ID またはメールアドレス(123456789876543212345my-iam-account@somedomain.com など)としてフォーマットする必要があります。

    出力には、既存のバインディングが含まれます。存在しない場合は、次のような etag 値が含まれます。

    {
    "etag": "BwUjHYKJUiQ="
    }
    
  2. 出力を policy.json という名前の新しいファイルにコピーします。

  3. Secure Source Manager サービス エージェントにサービス アカウント トークン作成者(roles/iam.ServiceAccountTokenCreator)ロールを付与するには、policy.json を変更して次のように追加します。

    {
        "role": "roles/iam.serviceAccountTokenCreator",
        "members": [
            "serviceAccount:service-INSTANCE_PROJECT_NUMBER@gcp-sa-sourcemanager.iam.gserviceaccount.com"
        ]
    }
    

    ここで、INSTANCE_PROJECT_NUMBER は Secure Source Manager インスタンスのプロジェクト番号です。

  4. 次のコマンドを実行して、サービス アカウントの既存の IAM ポリシーを置き換えます。

    gcloud iam service-accounts set-iam-policy SERVICE_ACCOUNT POLICY_FILE
    

    次のように置き換えます。

    • SERVICE_ACCOUNT は、サービス アカウント ID またはメールアドレスに置き換えます。
    • POLICY_FILE は、新しいポリシーを含む JSON 形式のファイルの場所と名前に置き換えます。

サービス アカウントにリポジトリ ロールを付与する

  1. Secure Source Manager ウェブ インターフェースで、サービス アカウントに権限を付与するリポジトリに移動します。
  2. [権限] タブをクリックします。
  3. [ユーザーを追加] をクリックします。
  4. [プリンシパルを追加] フィールドに、サービス アカウントのメールアドレスを入力します。
  5. [ロール] プルダウン メニューで、[Secure Source Manager Repository Reader] を選択します。
  6. 次のコマンドを実行して、サービス アカウントに securesourcemanager.instanceAccessor ロールを割り当てます。

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:SA_EMAIL \
        --role=roles/securesourcemanager.instanceAccessor
    

    次のように置き換えます。

    • PROJECT_ID は、Secure Source Manager インスタンスのプロジェクト ID に置き換えます。
    • SA_EMAIL は、サービス アカウントのメールアドレスに置き換えます。

Webhook を設定する

  1. Secure Source Manager ウェブ インターフェースで、Webhook を作成するリポジトリに移動します。
  2. [設定] をクリックします。
  3. [Webhooks] をクリックし、[Add webhook] をクリックします。
  4. [Hook ID] フィールドに、Webhook の ID を入力します。

  5. [Target URL] フィールドに、Jenkins トリガー URL を入力します。

  6. Jenkins トリガーの構成時にオプションのトークンを使用した場合は、Jenkins トリガー URL の末尾にそのトークンが含まれます。トークンが漏洩しないように、ターゲット URL の末尾から削除して [Sensitive Query String] フィールドにコピーします。

    トリガー URL でトークンを見つけるには、token= で始まるテキストを探します。

    たとえば、URL が次のようになっている場合: https://jenkins-server.com/generic-webhook-trigger/invoke?token=jenkins-job1

    疑問符 ?token=jenkins-job1 で始まる部分をコピーして、[Target URL] フィールドから削除します。次に、最初の疑問符を削除し、残りの部分 token=jenkins-job1 を [Sensitive Query String] フィールドに移動します。

  7. [Trigger on] セクションで、次のいずれかを選択します。

    • Push: リポジトリへの push でトリガーします。
    • Pull request state changed: pull リクエストの状態が変更されたときにトリガーします。
  8. [Push] を選択した場合は、 [Branch filter] フィールドに push イベントの許可リストを入力できます。

    [Branch filter] フィールドでは glob パターンが使用され、一致するブランチに対するオペレーションのみがビルドトリガーを引き起こします。フィールドが空か * の場合、すべてのブランチの push イベントが報告されます。

  9. [Add webhook] をクリックします。

  10. Webhook が [Webhook] ページに表示されます。

Webhook をテストする

  1. Secure Source Manager の [Webhook] ページで、テストする Webhook をクリックします。
  2. ページの一番下までスクロールして [Test delivery] をクリックします。

    配信キューに偽のイベントが追加されます。配信履歴に表示されるまでに数秒かかることがあります。

  3. git コマンドを使用して、pull リクエストを push またはマージして Webhook をテストすることもできます。

  4. Jenkins プロジェクトで、テストイベントによってトリガーされたビルドを [Build History] で確認します。

  5. 最初のテスト配信を送信した後、Secure Source Manager Webhook ページの [Recent deliveries] セクションで、テスト配信の [Request] と [Response] を確認することもできます。

次のステップ