Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen von Webhooks benötigen:
Rufen Sie in der Secure Source Manager-Weboberfläche das Repository auf, für das Sie einen Webhook erstellen möchten.
Klicken Sie auf Einstellungen.
Klicken Sie auf Webhooks und dann auf Webhook hinzufügen.
Geben Sie im Feld Hook-ID eine ID für den Webhook ein.
Geben Sie im Feld Ziel-URL die Webhook-URL ein. Wenn Sie beispielsweise einen Build in Jenkins auslösen möchten, können Sie einen Webhook-Trigger einrichten und dann hier die Jenkins-Trigger-URL eingeben, um den Build in Jenkins auszulösen.
Wenn die Webhook-URL die Schlüssel- und Geheimniswerte enthält, die Sie beim Erstellen des Webhook-Triggers eingegeben haben, entfernen Sie sie vom Ende der Ziel-URL und kopieren Sie sie in das Feld Sensitiver Abfragestring.
Wenn Sie Ihren Schlüssel und Ihr Secret in Ihrer Webhook-URL finden möchten, suchen Sie nach dem Text, der mit key= beginnt.
Beispiel: Bei der folgenden URL:
https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager
Kopieren Sie den Teil ab dem Fragezeichen ?key=... aus dem Feld Ziel-URL und entfernen Sie ihn. Entfernen Sie dann das ursprüngliche Fragezeichen und verschieben Sie den verbleibenden Teil key=... in das Feld Sensibler Abfragestring.
Wählen Sie im Bereich Auslösen bei eine der folgenden Optionen aus:
Push: wird ausgelöst, wenn ein Push an das Repository erfolgt.
Pull-Anfrage-Status geändert: Wird ausgelöst, wenn sich der Status der Pull-Anfrage ändert.
Wenn Sie Push ausgewählt haben, können Sie im Feld Branch-Filter eine Zulassungsliste für Push-Ereignisse eingeben.
Im Feld Branch filter wird das Glob-Muster verwendet. Nur Vorgänge in den übereinstimmenden Branches lösen einen Build aus. Wenn das Feld leer oder * ist, werden Push-Ereignisse für alle Zweige gemeldet. Informationen zur Syntax finden Sie in der glob-Dokumentation.
Klicken Sie auf Add webhook (Webhook hinzufügen).
Der Webhook wird auf der Seite Webhooks angezeigt.
Webhook testen
Klicken Sie in Secure Source Manager auf der Seite Webhooks auf den Webhook, den Sie testen möchten.
Klicken Sie unten auf der Seite auf Zustellung testen.
Der Zustellungswarteschlange wird ein Platzhalterereignis hinzugefügt. Es kann einige Sekunden dauern, bis sie im Zustellungsverlauf angezeigt wird.
Sie können auch einen git-Befehl verwenden, um einen Pull-Request zu pushen oder zusammenzuführen und den Webhook zu testen.
Prüfen Sie den Status des ausgelösten Builds oder Ereignisses im Build-Verlauf des Dienstes, in dem Sie den Webhook-Trigger konfiguriert haben.
Nachdem Sie Ihre erste Testübermittlung gesendet haben, können Sie sich auf der Webhook-Seite von Secure Source Manager im Bereich Letzte Übermittlungen auch die Anfrage und Antwort für die Testübermittlung ansehen.
Cloud Build-YAML-Variablen durch Nutzlastdaten ersetzen
Wenn Sie Webhooks verwenden, um eine Verbindung zu Cloud Build herzustellen, können Sie Cloud Build-YAML-Variablen durch Daten aus der Secure Source Manager-Webhook-Nutzlast ersetzen.
Klicken Sie in Secure Source Manager auf der Seite Webhooks im Bereich Letzte Zustellungen auf die oberste Zeile.
Der Request-Header und der Inhalt, der von der Webhook-Nutzlast gesendet wird, werden angezeigt.
Rufen Sie das Cloud Build-Dashboard auf und klicken Sie auf Trigger.
Klicken Sie auf den Trigger, den Sie konfigurieren möchten.
Klicken Sie im Bereich „Erweitert“ unter Substitutionsvariablen auf + Variable hinzufügen.
Geben Sie den Namen und den Wert der Variablen ein. Das Wertpräfix ist body.
Wenn Sie beispielsweise _REPO_URL durch das Nutzlastdatenfeld repository.clone_url und _COMMIT_SHA durch den SHA des letzten Commits in der Cloud Build-YAML-Datei ersetzen möchten, geben Sie die folgenden Namen und Werte ein:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[],[],null,["# Set up webhooks\n\nThis page describes how to set up webhooks in Secure Source Manager.\n\nWebhooks are HTTP requests triggered by an event in Secure Source Manager, and\nsent to a user-specified URL.\n\nBefore you begin\n----------------\n\n1. [Create a Secure Source Manager instance](/secure-source-manager/docs/create-instance).\n2. [Create a Secure Source Manager repository](/secure-source-manager/docs/create-repository).\n\n### Required roles\n\n\nTo get the permissions that\nyou need to create webhooks,\n\nask your administrator to grant you the\nfollowing IAM roles:\n\n- [Secure Source Manager Repository Admin](/iam/docs/roles-permissions/securesourcemanager#securesourcemanager.repoAdmin) (`roles/securesourcemanager.repoAdmin`) on the Secure Source Manager repository\n- [Secure Source Manager Instance Accessor](/iam/docs/roles-permissions/securesourcemanager#securesourcemanager.instanceAccessor) (`roles/securesourcemanager.instanceAccessor`) on the Secure Source Manager instance\n\n\nFor more information about granting roles, see [Manage access to projects, folders, and organizations](/iam/docs/granting-changing-revoking-access).\n\n\nYou might also be able to get\nthe required permissions through [custom\nroles](/iam/docs/creating-custom-roles) or other [predefined\nroles](/iam/docs/roles-overview#predefined).\n\nFor information on granting Secure Source Manager roles,\nsee [Access control with IAM](/secure-source-manager/docs/access-control) and\n[Grant users instance access](/secure-source-manager/docs/grant-users-instance-access).\n\nSet up a webhook\n----------------\n\n1. In the Secure Source Manager web interface, navigate to the repository you want to create a webhook for.\n2. Click **Settings**.\n3. Click **Webhooks** , and then click **Add webhook**.\n4. In the **Hook ID** field, enter an ID for the webhook.\n\n | **Note:** Hook IDs must follow the [resource naming convention](https://google.aip.dev/122#resource-id-segments). They must include only lower case letters, numbers, or dashes, must begin with a letter, and cannot be changed after creating the webhook.\n5. In the **Target URL** field, enter the Webhook URL. For example, if you want\n to trigger a build in Jenkins, you could\n [Set up a webhook trigger](/secure-source-manager/docs/connect-jenkins#set_up_a_webhook_trigger), and then enter\n the Jenkins trigger URL here to trigger your build in Jenkins.\n\n6. If the Webhook URL contains your key and secret values entered when you\n created your webhook trigger, remove them from the end of the target URL\n and copy them to the **Sensitive Query String** field.\n\n To locate your key and secret in your webhook URL, look for the text\n starting with `key=`\n\n For example, given the following URL:\n `https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager`\n\n Copy and remove the portion starting with the question mark\n `?key=...` from the **Target URL** field. Then remove the initial question\n mark, move the remaining portion `key=...` to the **Sensitive Query String**\n field.\n7. In the **Trigger on** section, select one of the following:\n\n - **Push**: to trigger on a push to the repository.\n - **Pull request state changed**: to trigger on a change in the pull request state.\n8. If you selected **Push** , then you can enter an allowlist for push events in\n the **Branch filter** field.\n\n The **Branch filter** field uses the glob pattern and only operations on the\n matched branches will cause a build trigger. If the field is empty or `*`,\n then push events for all branches are reported. For information on syntax,\n see the [glob](https://pkg.go.dev/github.com/gobwas/glob) documentation.\n9. Click **Add webhook**.\n\n10. The webhook is displayed in the **Webhooks** page.\n\n | **Note:** When you add or edit a webhook, the length of the `Sensitive Query String` might be inconsistent with the entered one, which is expected as placeholder strings are used to ensure security.\n\nTest your webhook\n-----------------\n\n1. In the Secure Source Manager **Webhooks** page, click the webhook you want to test.\n2. Go to the bottom of the page and click **Test delivery**.\n\n A placeholder event is added to the delivery queue. It might take a few\n seconds before it shows up in the delivery history.\n3. You can also use a `git` command to push or merge a pull request to test the\n webhook.\n\n4. Check the status of the triggered build or event in the build history of the\n service where you configured your webhook trigger.\n\n5. You can also view the **Request** and **Response** to the test delivery\n in the **Recent deliveries** section of the Secure Source Manager\n webhook page after you send your first test delivery.\n\nSubstitute Cloud Build YAML variables with payload data\n-------------------------------------------------------\n\nIf you're using webhooks to connect to Cloud Build, you can substitute\nCloud Build YAML variables with Secure Source Manager webhook payload\ndata.\n\n1. In the Secure Source Manager **Webhooks** page, in the **Recent deliveries**\n section, click the top row.\n\n The **Request** header and content sent by the webhook payload is displayed.\n2. Navigate to the Cloud Build dashboard, and then click **Triggers**.\n\n3. Click the trigger you want to configure.\n\n4. In the **Advanced section** , under **Substitution variables** , click\n **+ Add variable**.\n\n5. Enter the name and value of the variable. The value prefix is `body`.\n\n For example, to substitute `_REPO_URL` with the payload data field\n `repository.clone_url` and `_COMMIT_SHA` with latest commit sha in\n Cloud Build YAML, enter the following names and values:\n - Variable 1: `_REPO_URL` Value 1: `$(body.repository.clone_url)`\n - Variable 2: `_COMMIT_SHA` Value 2: `$(body.after)`\n\n The Cloud Build YAML file resembles the following: \n\n steps:\n - name: gcr.io/cloud-builders/git\n env:\n - '_REPO_URL=$_REPO_URL'\n - '_COMMIT_SHA=$_COMMIT_SHA'\n script: |\n #!/bin/sh\n git clone ${_REPO_URL} /workspace\n cd /workspace\n git reset --hard ${_COMMIT_SHA}\n\nWhat's next\n-----------\n\n- [Connect to Jenkins](/secure-source-manager/docs/connect-jenkins)"]]
