Container runner implementation that uses OCI container instances.
Container runner implementation that uses OCI container instances.
Max msecs to wait until container has started
Max msecs to wait until container has started
(instance-config {:keys [job build oci] :as conf})
Generates the configuration for the container instance. It has
a container that runs the job, as configured in the :job
, and
next to that a sidecar that is responsible for capturing the output
and dispatching events. If configured, it also
Generates the configuration for the container instance. It has a container that runs the job, as configured in the `:job`, and next to that a sidecar that is responsible for capturing the output and dispatching events. If configured, it also
Max number of cpu's to assign to a pod
Max number of cpu's to assign to a pod
Max memory that can be assigned to a pod, in gbs
Max memory that can be assigned to a pod, in gbs
(wait-for-instance-end-events events sid job-id max-timeout)
Checks the incoming events to see if a container and job end event has been received.
Returns a deferred that will contain both events, or that times out after max-timeout
.
Checks the incoming events to see if a container and job end event has been received. Returns a deferred that will contain both events, or that times out after `max-timeout`.
(wait-for-results {:keys [events job build]} max-timeout get-details)
Waits for the container end event, or times out. Afterwards, the full container instance details are fetched. The exit codes in the received events are used for the container exit codes.
Waits for the container end event, or times out. Afterwards, the full container instance details are fetched. The exit codes in the received events are used for the container exit codes.
(wait-for-startup events sid job-id)
Waits until a container start event has been received. This is the indication that user code is running, so we can send out a job/start event and register the job start time. If a sidecar error is received before that, it means something is wrong.
Waits until a container start event has been received. This is the indication that user code is running, so we can send out a job/start event and register the job start time. If a sidecar error is received before that, it means something is wrong.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close