Skip to main content
Version: Early Access

Lifecycle of Release Runner

This topics describes the lifecycle, control commands, and the different states of a Release Runner, with regards to the availability of the Release server.

Register Runners​

After the Release Runner is installed and running in a container, it automatically register itself with the provided Release URL using the configured Release Personal Access Token (PAT). For more information, see Installation Options Reference for Digital.ai Release with Runner.

note

During the initial execution or first run, Release Runner prepares and generates its configuration data that is used for registration. Runner name and version are read from the configuration, while UUID, public/private key pair are generated by the runner itself.

At this point, Release Runner sends a register request to Release Runner API. This request is retried by the Runner until a valid response from Release is received. For example, if Release is unavailable at that point or if the PAT is not valid.

After successful registration, Release Runner receives configuration data from Release that is needed for authorization, encryption and decryption of task and script data, along with the task executor configuration such as pool size and eviction time.

At this point, Release Runner also initiates SSE connection to Release, which is used to send control commands from Release to Runner. Control commands for enabling, disabling, deleting, and pinging are sent through this channel.

Once registered, the Release Runner is ready for the execution phase.

Readiness and Liveness of Runners​

Release Runner has two endpoints for readiness and liveness that checks for the current status of Runner's readiness and liveness respectively. These endpoints are used in the Kubernetes cluster to propagate container events and status.

  • Runner is ready if it successfully registers against the Release server
  • Runner is alive if the service starts

Additionally, Release server checks for the health of Runner by sending ping control command over an SSE channel. If ping is not received for more than 30 seconds, then the Runner will initiate a health check of the connection towards Release by restarting the SSE channel. In case the health check towards Release fails, the Runner will transition into the Idle state, attempting to recover the connections to Release.

Disable and Enable Runner​

The Release server has the capability to send Disable and Enable commands. These commands are transmitted during the shutdown and startup of Release, or they can be manually triggered by enabling or disabling the Runner configuration item.

  • When Disable command is received, the Runner stops doing reserve requests towards Release and stops the SSE channel.
  • When Enable command is received, the Runner initiates execution reservation process once again and the SSE channel is re-established.

Delete Runners​

In case the Release Runner is deleted from the Release server configuration a Delete control command is sent to the Runner. This command will initiate shutdown of the Runner. However, before it's shutdown, it will do a clean-up of any data and configuration stored on the system. At the end of the shutdown process, it will exit and terminate the container.