Set up webhooks

This page describes how to set up webhooks in Secure Source Manager.

Webhooks are HTTP requests triggered by an event in Secure Source Manager, and sent to a user-specified URL.

Before you begin

  1. Create a Secure Source Manager instance .
  2. Create a Secure Source Manager repository .

Required roles

To get the permissions that you need to create webhooks, ask your administrator to grant you the following IAM roles:

For more information about granting roles, see Manage access to projects, folders, and organizations .

You might also be able to get the required permissions through custom roles or other predefined roles .

For information on granting Secure Source Manager roles, see Access control with IAM and Grant users instance access .

Set up a webhook

  1. In the Secure Source Manager web interface, navigate to the repository you want to create a webhook for.
  2. Click Settings.
  3. Click Webhooks, and then click Add webhook.
  4. In the Hook IDfield, enter an ID for the webhook.

  5. In the Target URLfield, enter the Webhook URL. For example, if you want to trigger a build in Jenkins, you could Set up a webhook trigger , and then enter the Jenkins trigger URL here to trigger your build in Jenkins.

  6. If the Webhook URL contains your key and secret values entered when you created your webhook trigger, remove them from the end of the target URL and copy them to the Sensitive Query Stringfield.

    To locate your key and secret in your webhook URL, look for the text starting with key=

    For example, given the following URL: https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager

    Copy and remove the portion starting with the question mark ?key=... from the Target URLfield. Then remove the initial question mark, move the remaining portion key=... to the Sensitive Query Stringfield.

  7. In the Trigger onsection, select one of the following:

    • Push: to trigger on a push to the repository.
    • Pull request state changed: to trigger on a change in the pull request state.
  8. If you selected Push, then you can enter an allowlist for push events in the Branch filterfield.

    The Branch filterfield uses the glob pattern and only operations on the matched branches will cause a build trigger. If the field is empty or * , then push events for all branches are reported. For information on syntax, see the glob documentation.

  9. Click Add webhook.

  10. The webhook is displayed in the Webhookspage.

Test your webhook

  1. In the Secure Source Manager Webhookspage, click the webhook you want to test.
  2. Go to the bottom of the page and click Test delivery.

    A placeholder event is added to the delivery queue. It might take a few seconds before it shows up in the delivery history.

  3. You can also use a git command to push or merge a pull request to test the webhook.

  4. Check the status of the triggered build or event in the build history of the service where you configured your webhook trigger.

  5. You can also view the Requestand Responseto the test delivery in the Recent deliveriessection of the Secure Source Manager webhook page after you send your first test delivery.

Substitute Cloud Build YAML variables with payload data

If you're using webhooks to connect to Cloud Build, you can substitute Cloud Build YAML variables with Secure Source Manager webhook payload data.

  1. In the Secure Source Manager Webhookspage, in the Recent deliveriessection, click the top row.

    The Requestheader and content sent by the webhook payload is displayed.

  2. Navigate to the Cloud Build dashboard, and then click Triggers.

  3. Click the trigger you want to configure.

  4. In the Advanced section, under Substitution variables, click + Add variable.

  5. Enter the name and value of the variable. The value prefix is body .

    For example, to substitute _REPO_URL with the payload data field repository.clone_url and _COMMIT_SHA with latest commit sha in Cloud Build YAML, enter the following names and values:

    • Variable 1: _REPO_URL Value 1: $(body.repository.clone_url)
    • Variable 2: _COMMIT_SHA Value 2: $(body.after)

    The Cloud Build YAML file resembles the following:

      steps 
     : 
     - 
      
     name 
     : 
      
     gcr.io/cloud-builders/git 
      
     env 
     : 
      
     - 
      
     '_REPO_URL=$_REPO_URL' 
      
     - 
      
     '_COMMIT_SHA=$_COMMIT_SHA' 
      
     script 
     : 
      
     | 
      
     #!/bin/sh 
      
     git clone ${_REPO_URL} /workspace 
      
     cd /workspace 
      
     git reset --hard ${_COMMIT_SHA} 
     
    

What's next

Create a Mobile Website
View Site in Mobile | Classic
Share by: