Cron jobs¶

Cron jobs help you define a test case, schedule it and forget about it :)

In order to create a Cron job, we’ve reused the Tests logic, meaning that this page is pretty much similar to the Tests one.

However, we’re going to publish the same information twice, just to be sure everyone can follow it.

We’ve created a JSON Editor that has full semantic and syntax check so that it’s as easy as possible to define a test case.

You have the possibility of:

saving your work locally to a JSON file for later use
loading your work from a JSON file
copying a test case that on your colleague’s made and reuse it’s logic

Permissions¶

Member role vs API call	List crons	Create cron	Set cron status	Get cron details	Remove cron
Reader	True	False	False	True	False
Editor	True	True	True	True	True
Admin	True	True	True	True	True
Owner	True	True	True	True	True

Cron properties¶

The properties that can set up for yout tests are:

num_clients:
- Property type: MANDATORY
- Value type: Integer
- Explanation: Number of clients to spawn per EACH thread
- Restrictions: Minimum is 1 and Maximum depends on your subscription type
hatch_rate:
- Property type: MANDATORY
- Value type: Integer
- Explanation: Rate of clients to spawn per EACH thread. It helps you define if all virtual users should start for each thread should start at once, or if they should progressively be launched at 1-second intervals
- Restrictions: Should be equal or less to “num_clients” value, but higher than 1
run_time:
- Property type: MANDATORY
- Value type: Integer
- Explanation: How long should the test run for in seconds
- Restrictions: Minimum is 1 (second) and Maximum is 3600 (seconds), depending on your subscription type
threads_per_region:
- Property type: MANDATORY
- Value type: Integer
- Explanation: The number of containers to spawn in paralel in each region
- Restrictions: Minimum is 1 and Maximum is 25, depending on your subscription type
domain_name:
- Property type: MANDATORY
- Value type: String
- Explanation: Domain name to run the test against
- Restrictions: Must be a domain that is already validated or sub-domain of a domain that is already validated
protocol:
- Property type: MANDATORY
- Value type: String
- Explanation: Protocol to run the test against
- Restrictions: Can be either “http” or “https”
min_wait:
- Property type: OPTIONAL (default value is 1000)
- Value type: Integer
- Explanation: Minimum time for clients to wait before doing another request in milliseconds
- Restrictions: Minimum value is 0 (milliseconds) and Maximum value is 10.000 (milliseconds) (min = 0 and max = 10000)
max_wait:
- Property type: OPTIONAL (default value is 1000)
- Value type: Integer
- Explanation: Maximum time for clients to wait before doing another request in milliseconds
- Restrictions: Minimum value is 0 (milliseconds) and Maximum value is 10.000 (milliseconds), but definitely higher than min_wait
test_region:
- Property type: MANDATORY
- Value type: Array of Strings
- Explanation: Array of one or more regions to run the test in
- Restrictions: Values must include one or more of the following

["ap-northeast-1", "ap-northeast-2", "ap-southeast-1", "ap-southeast-2", "eu-central-1", "eu-west-1", "eu-west-2", "eu-west-3", "us-east-1", "us-east-2", "us-west-1", "us-west-2", "ca-central-1", "ap-south-1", "sa-east-1"]
These values emulate the following regions:
ap-northeast-1 = Tokyo
ap-northeast-2 = Seoul
ap-southeast-1 = Singapore
ap-southeast-2 = Sydney
eu-central-1 = Frankfurt
eu-west-1 = Ireland
eu-west-2 = London
eu-west-3 = Paris
us-east-1 = North Virginia
us-east-2 = Ohio
us-west-1 = North California
us-west-2 = Oregon
ca-central-1 = Canada (Central)
ap-south-1 = Mumbai
sa-east-1 = Sao Paulo

login:
- Property type: OPTIONAL (default is a blank object)
- Value type: Object
- Explanation: Object-based logic to execute in order to fetch authentication for workflow list
- Object properties:
  10.1. path:
  Property type: MANDATORY
  
  Value type: String
  
  Explanation: Path to login against
  
  Restrictions: Must start with a “/”
  10.2. method:
  Property type: MANDATORY
  
  Value type: String
  
  Explanation: Method to use for login
  
  Restrictions: Must be one of [“GET”, “POST”, “PATCH”, “HEAD”, “PUT”, “DELETE”, “OPTIONS”]
  10.3. data:
  Property type: OPTIONAL (default is a blank string)
  
  Value type: String
  
  Explanation: Data to include as parameters in the body of the request (aka payload)
  10.4. headers:
  Property type: OPTIONAL (default is a blank object)
  
  Value type: Key-Value object
  
  Explanation: Any key-value pair to include as headers in the request
  
  Restrictions: Include key-value pairs (eg {“Authorization”: “Basic nginx-auth-code-here”})
  10.5. get_token:
  Property type: MANDATORY
  
  Value type: Key-Value object
  
  Explanation: Object-based logic to fetch and inject auth token in workflow steps
  
  Object properties:
  
  10.5.1. from:
  
  Property type: MANDATORY
  
  Value type: String
  
  Explanation: Where to get the token from
  
  Restrictions: Can be either “headers” or “response”
  
  10.5.2. key:
  
  Property type: MANDATORY
  
  Value type: String
  
  Explanation: The response or header key to get the token from (eg “access_key” or “Cookie”)
  
  10.5.3. inject_as_header_key:
  
  Property type: MANDATORY
  
  Value type: String
  
  Explanation: The name of the header to include the token in the workflow steps (eg “Authentication”)
  
  10.5.4. inject_prefix_header_value:
  
  Property type: OPTIONAL (default value is blank string)
  
  Value type: String
  
  Explanation: A prefix (if necessary) to include before the token header value (eg “Bearer “)
workflow:
- Property type: MANDATORY
- Value type: Array of Objects
- Explanation: Array of object-based steps to execute sequentially
- Object properties:
  11.1. path:
  Property type: MANDATORY
  
  Value type: String
  
  Explanation: Path to test against
  
  Restrictions: Must start with a “/”
  11.2. method:
  Property type: MANDATORY
  
  Value type: String
  
  Explanation: Method to test against
  
  Restrictions: Must be one of [“GET”, “POST”, “PATCH”, “HEAD”, “PUT”, “DELETE”, “OPTIONS”]
  11.3. data:
  Property type: OPTIONAL (default is a blank string)
  
  Value type: String
  
  Explanation: Data to include as parameters in the body of the request (aka payload)
  11.4. headers:
  Property type: OPTIONAL (default is a blank object)
  
  Value type: Key-Value object
  
  Explanation: Any key-value pair to include as headers in the request

Extra parameters required only when creating Cron jobs via API calls:

12.1. schedule_type:

Property type: MANDATORY

Value type: String

Explanation: The schedule type to run the cron as

Restrictions: Can be either “DAILY”, “WEEKLY”, or “MONTHLY”

12.2. schedule_weekday:

Property type: OPTIONAL (required only if “schedule_type” is “WEEKLY”)

Value type: String

Explanation: The day of the week to launch the cron

Restrictions: Can be one of [“MON”, “TUE”, “WED”, “THU”, “FRI”, “SAT”, “SUN”]

12.3. schedule_day_of_month:

Property type: OPTIONAL (required only if “schedule_type” is “MONTHLY”)

Value type: Integer

Explanation: The day of the month to launch the cron

Restrictions: Can be one any number between 1 and 31

12.4. schedule_hour:

Property type: MANDATORY

Value type: Integer

Explanation: The hour to start the cron at (part of HH:MM logic)

Restrictions: Can be one any number between 0 and 24

12.5. schedule_minute:

Property type: MANDATORY

Value type: Integer

Explanation: The minute to start the cron at (part of HH:MM logic)

Restrictions: Can be one any number between 0 and 60

List crons¶

Web¶

In order to view the crons on our platform, all you have to do is browse to the Dashboard page.

API call¶

The API call is:

curl -s \
    -d '{"team_id":"my-team"}' \
    -H "X-Api-Key: my_api_key" \
    -X POST \
    https://api.rungutan.com/v1/api/cron/list | jq . -r

{
  "Crons": [
    {
        "cron_id": "some_cron_id",
        "cron_enabled": "true",
        "domain_name": "my-team.com",
        "threads_per_region": 1,
        "num_clients": 30,
        "hatch_rate": 30,
        "created_date": "2020-03-26T17:46:24Z",
        "run_time": "30s",
        "member_email": "[email protected]",
        "test_region": "us-east-1",
        "cron_expression": "cron(4 4 ? * THU *)"
    },
    {
        "cron_id": "some_cron_id_2",
        "cron_enabled": "false",
        "domain_name": "my-team.com",
        "threads_per_region": 1,
        "num_clients": 30,
        "hatch_rate": 30,
        "created_date": "2020-03-26T17:46:24Z",
        "run_time": "30s",
        "member_email": "[email protected]",
        "test_region": "us-east-1",
        "cron_expression": "cron(5 6 * * ? 27)"
    }
}

You can also filter based on test_id to generate the summary for only that specific test_id:

curl -s \
    -d '{"team_id":"my-team", "cron_id": "some_cron_id"}' \
    -H "X-Api-Key: my_api_key" \
    -X POST \
    https://api.rungutan.com/v1/api/cron/list | jq . -r

{
  "Crons": [
    {
        "cron_id": "some_cron_id",
        "cron_enabled": "true",
        "domain_name": "my-team.com",
        "threads_per_region": 1,
        "num_clients": 30,
        "hatch_rate": 30,
        "created_date": "2020-03-26T17:46:24Z",
        "run_time": "30s",
        "member_email": "[email protected]",
        "test_region": "us-east-1",
        "cron_expression": "cron(4 4 ? * THU *)"
    }
}

CLI¶

List all of them:

$ rungutan crons list
{
    "Crons": [
        {
            "cron_id": "a914cf1c-d7da-40c4-a47a-c42d56fb761d",
            "cron_enabled": "true",
            "domain_name": "rungutan.com",
            "threads_per_region": 1,
            "num_clients": 1,
            "hatch_rate": 1,
            "created_date": "2020-05-21T19:05:16Z",
            "run_time": 5,
            "member_email": "[email protected]",
            "test_region": "us-east-1",
            "cron_expression": "cron(34 16 ? * THU *)",
            "cron_name": "CRON - some scheduled job"
        }
    ]
}

Or filter based on cron_id:

$ rungutan crons list --cron_id a914cf1c-d7da-40c4-a47a-c42d56fb761d
{
    "Crons": [
        {
            "cron_id": "a914cf1c-d7da-40c4-a47a-c42d56fb761d",
            "cron_enabled": "true",
            "domain_name": "rungutan.com",
            "threads_per_region": 1,
            "num_clients": 1,
            "hatch_rate": 1,
            "created_date": "2020-05-21T19:05:16Z",
            "run_time": 5,
            "member_email": "[email protected]",
            "test_region": "us-east-1",
            "cron_expression": "cron(34 16 ? * THU *)",
            "cron_name": "CRON - some scheduled job"
        }
    ]
}

Start cron¶

Web¶

In order to start a new cron, all you have to do is browse to the Dashboard page and click on the Create cron button.

API call¶

The API call is:

curl -s \
    -d '{
        "schedule_type": "WEEKLY",
        "schedule_weekday": "TUE",
        "schedule_hour": 0,
        "schedule_minute": 4
        "team_id": "my-team",
        "num_clients": 30,
        "hatch_rate": 30,
        "run_time": 30,
        "threads_per_region": 1,
        "domain_name": "my-team.com",
        "protocol": "https",
        "min_wait": 1000,
        "max_wait": 1000,
        "test_region": [
            "us-east-1"
        ],
        "workflow": [
            {
                "path": "/",
                "method": "GET",
                "data": "",
                "headers": {}
            }
        ]}' \
    -H "X-Api-Key: my_api_key" \
    -X POST \
    https://api.rungutan.com/v1/api/cron/add | jq . -r

{
    "cron_id": "some_cron_id",
    "message": "Successfully created new cron"
}

CLI¶

Reuse your test file you already have and run it with the missing arguments:

$ rungutan crons add --test_file test_file.json --schedule_hour 22 --schedule_minute 33 --schedule_day_of_month 1 --schedule_type MONTHLY
{
    "cron_id": "e4df2e1d-efb0-4d7b-8ae8-92bb5c082456",
    "cron_name": "CRON - test from cli",
    "message": "Successfully created new cron"
}

Set cron status¶

Web¶

In order to set the status of a cron, all you have to do is browse to the Dashboard page and click on the Set status button for the respective cron.

API call¶

The API call is:

curl -s \
    -d '{
        "cron_id": "some_cron_id",
        "team_id": "my-team",
        "cron_enabled": "true"                  // A String that can be either "true" or "false"
        }' \
    -H "X-Api-Key: my_api_key" \
    -X POST \
    https://api.rungutan.com/v1/api/cron/set-status | jq . -r

{
    "cron_id": "some_cron_id",
    "message": "Successfully updated cron status",
}

CLI¶

Disable a cron:

$ rungutan crons set-status --cron_id 35a60d21-2ff3-4baf-bc4d-a233f332adfc --cron_enabled false
{
    "message": "Successfully updated cron status",
    "cron_id": "35a60d21-2ff3-4baf-bc4d-a233f332adfc"
}

Or enable it back:

$ rungutan crons set-status --cron_id 35a60d21-2ff3-4baf-bc4d-a233f332adfc --cron_enabled true
{
    "message": "Successfully updated cron status",
    "cron_id": "35a60d21-2ff3-4baf-bc4d-a233f332adfc"
}

Get cron details¶

Web¶

In order to get the details of a cron, all you have to do is browse to the Dashboard page and click on the Copy test details button for the respective cron.

API call¶

The API call is:

curl -s \
    -d '{
        "cron_id": "some_cron_id",
        "team_id": "my-team"
        }' \
    -H "X-Api-Key: my_api_key" \
    -X POST \
    https://api.rungutan.com/v1/api/cron/get | jq . -r

{
    "TestData": {
        "num_clients": 30,
        "hatch_rate": 30,
        "run_time": 30,
        "threads_per_region": 1,
        "workflow": [
            {
                "path": "/",
                "method": "GET",
                "data": "",
                "headers": {}
            }
        ],
        "domain_name": "my-team.com",
        "protocol": "https",
        "test_region": [
            "us-east-1"
        ],
        "min_wait": 1000,
        "max_wait": 1000
      }
}

CLI¶

Command will be added as soon as the CLI will be finished.

Remove cron¶

Web¶

Crons can be easily disabled and kept in your team for reference purposes.

Should you wish to remove one though, then all you have to do is browse to the Dashboard page and click on the Remove cron button for the respective cron.

API call¶

The API call is:

curl -s \
    -d '{
        "cron_id": "some_cron_id",
        "team_id": "my-team"
        }' \
    -H "X-Api-Key: my_api_key" \
    -X POST \
    https://api.rungutan.com/v1/api/cron/remove | jq . -r

{
    "message": "Successfully removed cron",
    "cron_id": "some_cron_id"
}

CLI¶

Drop it like it’s hot:

$ rungutan crons remove --cron_id 35a60d21-2ff3-4baf-bc4d-a233f332adfc
{
    "message": "Successfully removed cron",
    "cron_id": "35a60d21-2ff3-4baf-bc4d-a233f332adfc"
}