In Runnerty, processes are calls to the executors. The executors are plugins which encapsulate functionalities. Know more about executors here.
There is a bunch of executors with different functionalities, have a look at the official here.
One of the most important executors could be the shell executor @runnerty/executor-shell. As it is the Command-Line Interface, with this plugin is possible to execute existing processes that you may already have.
Each process has two identification fields:
id is the unique identification string of the process.
name is a description of the process
With Runnerty is possible to establish dependencies betwwen processes. Runnerty provides a powerful feature for this task.
In the example below we can see how
PROCESS_ONE has a dependcien with
PROCESS_TWO. This way,
PROCESS_TWO will only start when
PROCESS_ONE had finished.
Not only it is possible to set up dependencies to other processes end states. You can also use operators to evaluate values, add complex conditions using operators and multiple expressions.
It is highly recommended to have a look at dependencies documentation here.
In the exec property are the fields that identify the executor that is going to be used and the params needed.
In this example we are using our shell_default executor, the configuration for this executor should be in our config.json file:
id field we are indicating the executor that we are going tov use. The rest of the fields are params for the executor. Know more about the executors and their usage in here. You can also chekc the config documentation to know how to configure them.
With runnerty we can configure a process to retry in case of error.
We only have to indicate the number of
retries for the process and optionally the delay (
retry_delay) between retries.
It is also possible to avoid the notifications
on_fail of the failed executions previous to the last attempt.
We can indicate that only the last fail
notificate_only_last_fail is notified.
In this example after the first execution failure, it will be retry up to 2 times with 1 second delays. And the error will only be reported in case the last attempt fails.
We also have the possibility to implement specific notifications for retries in the
The number of retries for a process can be obtained from
PROCESS_RETRIES_COUNT with the
@GETVALUES function, to know more about values here.
Runnerty also provides a notification system for your workflows. With the notifications property you can have access to the different states of the process:
"on_start", "on_fail", "on_retry", "on_end" and "on_queue" and use them to send notifications.
For this task, Runnerty uses notifiers, know more about them here.
This is an example of usage of notifications in a process. In this case, we are using the Telegram notifier to notify the different states of the process to a Telegram chat:
In the example it is used the value
PROCESS_ID, this value will have the id of the process. Know more about.
There is an official list of the available notifiers here.
Another property of ther processes is that we can redirect the output of a process to a file.
Runnerty provides some options to manage logs. Using the property
concat we can indicate Runnerty if we want to concatente the output or overwrite it.
With the maxsize option we indicate Runnerty the maximun size that the log's file could have. Runnerty will automatically delete the firt lines of the file when it is full and needs to continue writting.
Output Share (output_share)
The output_share property it is used to define values from the output of a process. Theses values area availables for the rest of the procesess of the chain.
In this example we are getting the email of an user from the database using the @runnerty/executor_mysql and assigning it to a value. This way we can use the
:USER_EMAIL value anywhere of the chain.
Note that in this example we are are using the value
PROCESS_EXEC_MSG_OUTPUT This is a global_value that contains the return of the process. Have a look at the values documentation.
The`output_iterable property it's used to iterate a chain depending of the output of a process. An iterable chain is a chain that is going to be executed for each object of the array returned by a process. For example, if we have a process which returns an objects array we can execute an iterable chain for each object of the array.
You can have a look at the chains documentation to see an usage example.
The timeout property it's used to set the maximun time to wait process ends.
It is possible to establish two different actions, end or error. If the "error" action is indicated, the process will end with a failure and if "end" is indicated the process will end without failure. In both cases the function "kill" of the executor in question will be called.
In addition to the action must indicate the mandatory property "delay" indicating the maximum timeout in milliseconds.
Delay property understands the following strings:
The space after the number is optional so you can also write
1ms instead of
1 ms. In addition to that it also accepts numbers and strings which only includes numbers and we assume that these are always in milliseconds.
From: [Millisecond module](https://github.com/unshiftio/millisecond)