Page History

...

The matching password for the user of the service.

Request Body

The request body is where the information for the request is placed. In the case above, the request expects a JSON object called payload. The object has two properties called name and icon_emoji - each with values provided for the given request. 

The values can have Continua CI variables included in them so that build information can be passed onto other systems. In the above example the text message passed onto the HTTP request includes the project name and build version number.  

Querystring Parameters

These parameters should be provided in <name>=<value> format. Each parameter will be added to the query string which is sent as part of the request. Adding query string parameters here means that you do not have to get the formatting correct for the HTTP query string yourself. All escaping is handled for you when using the querystring parameter entry box. 

...

Use this to add any get/post parameters for to the request. These are simple parameters that the endpoint may require or use to understand the request being made of it. These parameters should be provided in <name>=<value> format with each pair on a separate line.  

Headers

Allows for adding you to add header parameters for to the request. These should be entered in the <name>=<value> format with each pair on a separate line.  

Cookies

Allows for adding you to add cookie parameters for to the request. These should be entered in the <name>=<value> format with each pair on a separate line.  

Response Variables

Allows for These can be used to extracting values from JSON or XML responses and placing place them into configuration variables the configuration has access to. To extact extract values from the JSON and XML responses, JSONpath and XPath can be used. Each has their own syntax for extracting values for nodes within the objects they represent. Below is a list of some of the syntax allowed by each. 

Listed below is an example response in JSON and XML.

...

{ 
  "messages": {
    "staging": [ 
      { 
        "author"  : "tim_bot",
        "category": "information",
        "message" : "Building..."
      },
      { 
        "author"  : "tim_bot",
        "category": "information",
        "message" : "Testing..."
      },
      { 
        "author"  : "tim_bot",
        "category": "information",
        "message" : "Completed!"
      }
    ],
    "production": [
      { 
        "author"  : "jill_bot",
        "category": "information",
        "message" : "Building..."
      },
      { 
        "author"  : "jill_bot",
        "category": "error",
        "message" : "Build Failed!"
      }
    ]
  }
}

<?xml version="1.0" encoding="UTF-8" ?>
<messages>
  <staging>
    <author>tim_bot</author>
    <category>information</category>
    <message>Building...</message>
  </staging>
  <staging>
    <author>tim_bot</author>
    <category>information</category>
    <message>Testing...</message>
  </staging>
  <staging>
    <author>tim_bot</author>
    <category>information</category>
    <message>Completed!</message>
  </staging>
  <production>
    <author>jill_bot</author>
    <category>information</category>
    <message>Building...</message>
  </production>
  <production>
    <author>jill_bot</author>
    <category>error</category>
    <message>Build Failed!</message>
  </production>
</messages>

The following are example XPath and JSONPaths that could be used on the above responses to extract information your looking for.

Successful Response Statues

Check each of the response statuses that would mean the request has been successful. If the request returns a status that is not checked then the build event handler will report an error. If errors are to be treated as failures then the build event handler will fail the build at his point.