Triggers

Overview of triggers, which run Typhoon Test Hub jobs according to predefined conditions.

Defining when a Job should be executed is at the core of Test Automation, as this maintains a consistent order of Executions in the Queue. In Typhoon Test Hub, it is possible to create Manual, Periodic, or Event Triggers. They all have the same behavior but differ in the way they are started. You can see the most important information about triggers in the Triggers table. Here you can create a new trigger, update a trigger, or delete am existing one. Triggers can be one of the following types:

• Periodic - initiates the job execution at scheduled intervals or times
• Manual - enables users to initiate the execution of a job manually
• Event - responds to a specific event or condition in a system, triggering the execution of a job when a predefined event occurs

The triggers table shows the following information:

1. Type:
   • Periodic - Periodic Triggers run at a pre-defined interval – every day at 10pm, for example.
   • Manual - Manual Triggers are mostly used for quick and customized test executions. These triggers must be started manually.
   • Event - Event Triggers are the most flexible and allow integration with several other applications. Event Triggers create a trigger URL, which is used to start the execution externally. When an Event Trigger starts, it returns its Execution ID, which can be used to track if the execution is Queued, Running, Passed, or Failed. This information can be used to approve merge requests, for example. Here is a simple Python code snippet showing how you can trigger an Execution with parameters (all parameters must be set when doing so), wait for it to be done, and raise an exception in case it fails. If trigger has parameter that was created as parametrized field of either Job or Pipeline, those parameters are to be passed using the following naming: TTH_PARAMETER_AGENT, TTH_PARAMETER_SETUP, TTH_PARAMETER_TAG, all three available for Jobs and only TTH_PARAMETER_TAG available for Pipelines. Value of mentioned fields can be entered as following:
     • TTH_PARAMETER_AGENT=1
     • TTH_PARAMETER_AGENT=[1]
     • TTH_PARAMETER_AGENT=[1, 2]
     where numbers represent ids of the Agent (for the example above). In case of having one Agent id, it can be set as number, list containing that number, while when having multiple ids they need to be entered as a list of ids.

     import requests
     
     auth_token = 123456 # Replace with the token value of the trigger you want to start
     tth_url = "URL" # Replace URL with the URL of your TTH 
     trigger_id = 4  # Replace with the Trigger Number you would like to start
     branch = "main"
     
     trigger_url = f"{tth_url}/api/triggers/start/{trigger_id}"
     exec_id = requests.post(trigger_url, headers={'X-API-Key': auth_token}).json()
     exec_url = f"{tth_url}/api/executions/status/{exec_id}"
                    
     while True:
         exec_status = requests.get(exec_url,
                                    headers={'X-API-Key': auth_token},
                                    json={"parameters": [{"name": "BRANCH", "value": branch}]}).json()['status']
         if exec_status not in ['QUEUED', 'RUNNING']
             break
     
     if exec_status != 'PASSED':
         raise Exception("HIL Job did not pass!")                  

2. Name of trigger
3. Last time when a job was triggered by this trigger
4. Last duration of an execution made by this trigger

In the Actions column, you can also manually start and stop specific triggers.

Note: By clicking on the button, columns of the table can be customized - hidden or shown depending on the preference. Columns of the table can be reordered by using drag and drop in the table header. When positioning cursor in between two columns, cursor for column resizing will show and enable change of the column's width. All changes made to the table will be automatically preserved.

Trigger details

In the Details section, you can find:

1. Configuration tab: Here you can update the trigger data.
2. Executions tab: Contains triggered executions by the selected trigger.
3. Reports tab: Contains reports generated by the selected trigger.

You can also delete a trigger by clicking on the button. A trigger can be deleted only when there is no queued execution made by this trigger.

Create trigger

A new trigger can be added by clicking on the button. This opens the Add new trigger dialog shown in Figure 3.

Here you can:

1. Give a trigger a name, which will be used to refer to it throughout Typhoon Test Hub. Each name must be unique.
2. Select a trigger type and fill in the needed data.
3. Select a configuration (Job or Pipeline) you want to be triggered and assign parameter values if the configuration has parameters. Parameters will be listed under the configuration field with their names bolded.
4. Select Agent that will be used for the execution.
5. Select the timeout - the maximum allowed time for the execution of a job after the trigger is activated. This ensures that the execution completes within a defined time frame or is automatically terminated.

Within the advanced section, general retention policy can be enabled for executions, by defining for how long executions should be preserved. Policy can be defined in the following way:

• Preserve latest - where number of executions that would be preserved needs to be entered.
• Preserve for - where period needs to be entered (number and unit, where unit can be days/weeks/months/years) for which executions needs to be preserved.

The global retention policy can also be parameterized, and parameterized policies can be valuable when dealing with jobs, pipelines, or triggers that have different configurations or parameters and are used frequently. With parameterized policies, we can better filter out the executions we want to preserve based on their characteristics. Execution filters are used in order to filter executions and to write parametrized policy.

Once a parametrized retention policy is defined, it will be visible in the advanced section of the form.

Note: In order to save a form, all input fields must be valid. Required fields are signed with *.