Na interface da Web do Secure Source Manager, navegue até o repositório em que você quer
criar um webhook.
Clique em Configurações.
Clique em Webhooks e em Adicionar webhook.
No campo ID do hook, insira um ID para o webhook.
No campo URL de destino, insira o URL do webhook. Por exemplo, se você quiser
acionar um build no Jenkins, configure um gatilho de webhook e insira
o URL do gatilho do Jenkins aqui para acionar o build no Jenkins.
Se o URL do webhook contiver os valores de chave e segredo inseridos quando você
criou o gatilho do webhook, remova-os do final do URL de destino
e copie-os para o campo String de consulta sensível.
Para localizar sua chave e seu secret no URL do webhook, procure o texto
que começa com key=
Por exemplo, considerando o seguinte URL:
https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager
Copie e remova a parte que começa com o ponto de interrogação
?key=... do campo URL de destino. Em seguida, remova o ponto de interrogação inicial e mova a parte restante key=... para o campo String de consulta sensível.
Na seção Acionar em, selecione uma das seguintes opções:
Push: para acionar um envio para o repositório.
Estado da solicitação de pull alterado: para acionar uma mudança no estado da solicitação de pull.
Se você selecionou Push, insira uma lista de permissão para eventos de envio no campo Filtro de ramificação.
O campo Filtro de ramificação usa o padrão glob, e apenas operações nas ramificações correspondentes vão acionar um gatilho de compilação. Se o campo estiver vazio ou for *,
os eventos de push de todas as ramificações serão informados. Para informações sobre a sintaxe, consulte a documentação do glob.
Clique em Add webhook.
O webhook é exibido na página Webhooks.
Testar seu webhook
Na página Webhooks do Secure Source Manager, clique no webhook que você quer testar.
Role até a parte de baixo da página e clique em Testar entrega.
Um evento de marcador de posição é adicionado à fila de entrega. Pode levar alguns
segundos para que ele apareça no histórico de entrega.
Também é possível usar um comando git para enviar ou mesclar uma solicitação de envio e testar o
webhook.
Verifique o status do build ou evento acionado no histórico de builds do
serviço em que você configurou o gatilho de webhook.
Você também pode conferir o Pedido e a Resposta da entrega do teste na seção Entregas recentes da página do webhook do Secure Source Manager depois de enviar sua primeira entrega de teste.
Substituir variáveis YAML do Cloud Build por dados de payload
Se você estiver usando webhooks para se conectar ao Cloud Build, poderá substituir
variáveis YAML do Cloud Build por dados de payload de webhook do Secure Source Manager.
Na página Webhooks do Secure Source Manager, clique na linha superior da seção Entregas recentes.
O cabeçalho Request e o conteúdo enviado pelo payload do webhook são exibidos.
Acesse o painel do Cloud Build e clique em Gatilhos.
Clique no gatilho que você quer configurar.
Na seção Avançado, em Variáveis de substituição, clique em
+ Adicionar variável.
Insira o nome e o valor da variável. O prefixo do valor é body.
Por exemplo, para substituir _REPO_URL pelo campo de dados do payload
repository.clone_url e _COMMIT_SHA pelo sha do commit mais recente no
YAML do Cloud Build, insira os seguintes nomes e valores:
Variável 1: _REPO_URL Valor 1: $(body.repository.clone_url)
Variável 2: _COMMIT_SHA Valor 2: $(body.after)
O arquivo YAML do Cloud Build é semelhante a este:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-02 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)"]]
