Articles in this section

Sample GitLab Webhook (Versions: 10.3+)

QuerySurge has long emphasized team communication and information-sharing in its design. As part of that emphasis, webhook support was introduced in QuerySurge 10.0. With QuerySurge 10.3, we've added built-in support for GitLab Issue Creation via webhook.

 

This article describes the webhook setup for GitLab Issue creation.

 

GitLab provides a REST API, and in the following example, we set up a QuerySurge webhook that adds an issue to your GitLab repository. 

gitlab.png

  1. This is the URL template for GitLab REST API calls. Note that you'll need your specific Project ID to complete the URL. 
    https://gitlab.com/api/v4/projects/<YourProjectID>/issues
  2. GitLab uses a personal access tokens/private tokens to authenticate API requests. Personal access tokens in GitLab can be generated by navigating to your account Preferences/User Settings page and selecting “Access Tokens”. Once in the Access Tokens page, you will need to set the expiration date of the token as well as the selected scopes required. At a minimum, "api" access is required when selecting the scope access for your personal access token.

    2-Gitlab_Token.PNG
    After setting the expiration and selecting the scope, clicking on the "Create personal access token" button at the bottom of the screen will generate the new token. Note: Be sure to copy the token at this point as you will not be able to view it in GitLab again.
    The newly generated token can now be applied to your webhook template in QuerySurge. We will add and additional header under the Headers section. Header="PRIVATE-TOKEN" Value="<YourPersonalAccessToken>"
    gitlab2.png

  3. The JSON payload in this example is simple to moderate in complexity. The JSON must follow GitLab API syntax rules (consult the GitLab API documentation). There are a few items of note here. You can insert QuerySurge values into the message, denoted by the ${...} syntax. Finally, this example is a "plain-vanilla" issue-creation example, meaning there are no required custom fields. If you have required custom fields, you'll need to find out how they are named in the JSON (again, consult the documentation) and configure them with QuerySurge values or hardcoded values as needed.
    {
    "title": "Scenario ${scenarioName} has an outcome of: ${outcome}",
    "description": "Percent passing: ${passRate} %\nNumber of QueryPairs: ${numberOfQueryPairs}\n${queryPairsPassed} / ${numberOfQueryPairs} passed\n${queryPairsFailed} / ${numberOfQueryPairs} failed\n${queryPairsKilled}, ${queryPairWarnings}, ${queryPairErrors} killed, warning, errors\n\nRun Owner: ${owner}\nRun Start: ${startTime}\nRun End: ${endTime}\nDuration: ${duration}"
    }
  4. You have the option to add additional filters on an event. For example, you could limit the firing of the webhook to a specific owner (i.e. user), or in the "Scenario Ended" event, to whether the execution failed. The webhook Event Filters are identical to Email Notification Event Filters. For more information, see this.

  5. Your GitLab Issue looks like a standard issue (unless you have customized it).

GitLabIssue.png

 

Related articles