Nell'interfaccia web di Secure Source Manager, vai al repository per cui vuoi
creare un webhook.
Fai clic su Impostazioni.
Fai clic su Webhook e poi su Aggiungi webhook.
Nel campo ID hook, inserisci un ID per il webhook.
Nel campo URL di destinazione, inserisci l'URL webhook. Ad esempio, se vuoi attivare una build in Jenkins, puoi configurare un trigger webhook e poi inserire l'URL del trigger Jenkins qui per attivare la build in Jenkins.
Se l'URL webhook contiene i valori della chiave e del secret inseriti quando
hai creato il trigger webhook, rimuovili dalla fine dell'URL di destinazione
e copiali nel campo Stringa di query sensibile.
Per trovare la chiave e il secret nell'URL webhook, cerca il testo
che inizia con key=
Ad esempio, dato il seguente URL:
https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager
Copia e rimuovi la parte che inizia con il punto interrogativo
?key=... dal campo URL di destinazione. Poi rimuovi il punto interrogativo iniziale e sposta la parte rimanente key=... nel campo Stringa di query sensibile.
Nella sezione Attiva su, seleziona una delle seguenti opzioni:
Push: per attivare un push al repository.
Stato richiesta pull modificato: per attivare un evento in caso di modifica dello stato della richiesta pull.
Se hai selezionato Push, puoi inserire un elenco consentito per gli eventi push nel campo Filtro ramo.
Il campo Filtro ramificazioni utilizza il pattern glob e solo le operazioni sulle
ramificazioni corrispondenti attiveranno una build. Se il campo è vuoto o *,
vengono segnalati gli eventi push per tutti i rami. Per informazioni sulla sintassi,
consulta la documentazione relativa a glob.
Fai clic su Aggiungi webhook.
Il webhook viene visualizzato nella pagina Webhook.
Testare il webhook
Nella pagina Webhook di Secure Source Manager, fai clic sul webhook che vuoi
testare.
Vai in fondo alla pagina e fai clic su Test di pubblicazione.
Un evento segnaposto viene aggiunto alla coda di pubblicazione. Potrebbero essere necessari alcuni secondi prima che venga visualizzato nella cronologia delle consegne.
Puoi anche utilizzare un comando git per eseguire il push o unire una richiesta pull per testare il webhook.
Controlla lo stato della build o dell'evento attivato nella cronologia delle build del
servizio in cui hai configurato il trigger webhook.
Puoi anche visualizzare la richiesta e la risposta al test di pubblicazione
nella sezione Pubblicazioni recenti della pagina webhook di Secure Source Manager dopo aver inviato il primo test di pubblicazione.
Sostituisci le variabili YAML di Cloud Build con i dati del payload
Se utilizzi webhook per connetterti a Cloud Build, puoi sostituire
le variabili YAML di Cloud Build con i dati del payload del webhook di Secure Source Manager.
Nella pagina Webhook di Secure Source Manager, fai clic sulla prima riga della sezione Recapiti recenti.
Vengono visualizzati l'intestazione e i contenuti Request inviati dal payload del webhook.
Vai alla dashboard di Cloud Build, quindi fai clic su Trigger.
Fai clic sul trigger che vuoi configurare.
Nella sezione Avanzate, in Variabili di sostituzione, fai clic su
+ Aggiungi variabile.
Inserisci il nome e il valore della variabile. Il prefisso del valore è body.
Ad esempio, per sostituire _REPO_URL con il campo dati del payload
repository.clone_url e _COMMIT_SHA con l'ultimo SHA del commit in
Cloud Build YAML, inserisci i seguenti nomi e valori:
Variabile 1: _REPO_URL Valore 1: $(body.repository.clone_url)
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)"]]
