You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

The Http Request build event handler can be used to call any HTTP endpoint to signal the Continua CI build getting to a certain point, or status. You can create call any HTTP webhook or endpoint api that suits your needs, such as Slack channel messaging.

The build event handler can be set to automatically respond to any Build Events in the life-cycle of the build. This allows the HTTP endpoint to be hit at any stage of the build process.

Event Handler Name

Friendly name for the event handler (this will be visible in the 'Events' section of the website)

Run order

The order in which the event handler will be run (relevant in the situation where multiple event handlers are present).

Enabled

Whether this event handler will be run or not. Disabling event handlers can be useful when setting up a build process. 

Type

The type of event handler to be used. Set to HTTP Request to specify a HTTP request for the build event. 

Server URL

The server the HTTP endpoint to call exists on. Note that the Continua CI server will require access to the server as it is responsible for running build event handlers. Please make sure that the server is accessible from the machine your Continua CI server is installed on if experiencing any connectivity issues. 

Resource

The resource endpoint on the server that is to be requested. Note that this is just the pure path to the endpoint, any query strings can be added later in the query string section. 

Method

The method type to use in the request. The available options here are:

  • Get
  • Post
  • Put
  • Patch
  • Delete

The method should match what the endpoint requires so that the correct action or resource is accessed on the server. 

Data Format

The format the data sent or requested should be presented in. Note that the build event handler will attempt to parse response data in the format selected before extacting any variable values. If this parsing fails, the variable values will not be assigned. 

Also some HTTP endpoints require data to be sent in specific format. If the correct format is not used then the endpoint may fail with a Bad Request response. Make sure to set the data format required by the endpoint in question. 

The context-type header will also be set based on the data format selected. For example selecting JSON will mean the context-type header will be set to application/json.

Authentication Type

The type of authentication to use to interact with the specified endpoint. The types of authentication possible are:

  • None
  • Basic
  • NTLM
  • Access token as parameter
  • Credentials as parameter

The login method to use will be dependent on the endpoint in question. Some endpoints also offer token-based resource paths to alleviate the need to provide credentials. 

Basic & NTLM Authentication 

Username

The username to use for basic HTTP or NTLM authentication. Note that the username and password are base64 encoded into a basic authentication HTTP header for the request. 

Password

The password to use which matches the username listed above. 

Access Token as Parameter Authentication

Authentication Parameters Type

The type of parameter to send the access key token as. The valid values of Cookie, Form, Header, and QueryString determine where the authentication parameter will be placed in the request sent. 

Access Token Key Name

The name of the parameter for the token. This can differ from implementation to implementation of a HTTP service. Check with the service in question as to what the expected parameter name is for the key token. 

Access Token

The access token to use for the service. This should match the access level require for the requested service. 

Credentials as Parameters Authentication

Authentication Parameters Type

The type of parameter to send the access key token as. The valid values of Cookie, Form, Header, and QueryString determine where the authentication parameter will be placed in the request sent. 

Username Key Name

The name of the parameter for the username. This can differ from implementation to implementation of a HTTP service. Check with the service in question as to what the expected parameter name is for the username.

Username

The username of the user accessing the service. This user should have the level of access required to perform the action the HTTP request is asking for. 

Password Key Name

The name of the parameter for the password. This can differ from implementation to implementation of a HTTP service. Check with the service in question as to what the expected parameter name is for the password. 

Password

The matching passing 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 information that Continua CI has about the build can be passed onto other systems. In the above example the text message passed onto the HTTP request is writing out the project name, and build version number. 

 

Querystring Parameters

 

POST Parameters

 

Headers

 

Cookies

 

  • No labels