Creation pipeline

Note

Most of the information in the Lambda documentation also applies to jobs, with the exceptions noted in this chapter.

To create a job, a workflow must first be created or imported. A workflow can be created in two ways, similar to lambda creation: by providing an archive or by importing an existing Docker image. When an image is imported, the workflow is immediately ready for job creation. If no imported image is available (i.e., the workflow is created from a user-provided archive), the image is built and pushed to the registry automatically.

The image build process for workflows follows the same approach as for lambdas. Use the workflow image status request to check the build status and the workflow image logs request to retrieve build logs. Additionally, there is a dedicated workflow export request that allows exporting the image for subsequent import.

Immediately after creating a workflow, regardless of whether the image has been provided, is currently being built, or is queued for building, jobs can be created. Once the image is ready, it will appear in the imported image field of the get job response, and the job will be placed in the execution queue.

Jobs can be created in two ways: simultaneously with the workflow creation (by setting disabled: false in deploy_parameters), or separately via a POST request. Jobs created within a workflow will be deleted when the workflow is deleted (delete workflow). All main parameters described for lambdas work in the same way for jobs, unless otherwise specified in this chapter. Deleting a specific job (delete job) will not affect the workflow of that job or any other jobs within that workflow.

Creating a job, unlike creating a lambda, does not imply unconditional immediate or scheduled execution. Job execution starts automatically according to the rules described in the *Job Queue* chapter.

Job creation differs from lambda creation in several ways. First, the image for a job cannot be changed; it is inherited from the workflow. Additionally, pod_count cannot be specified for a job at this time. Currently, the number of pods for each enabled job is always one. All parameters provided during job creation, except for job name, in the credentials field are optional and will be inherited from the parent workflow. If parameters are specified, they will override the inherited values from the workflow.

The API for managing jobs is nearly identical to that for lambdas. It includes the following requests:

Job API requests

Request	Description	API Reference
get job	Get job by ID	GET
get jobs	Get jobs according to filters	GET
delete job	Remove job by ID	DELETE
get job logs	Get job logs	GET
get job documentation	Get job OpenAPI documentation	GET
Proxy requests	Proxy requests to job	POST/GET/HEAD/PUT/PATCH/DELETE
get job config	Get job config	GET
update job config	Update job config	PUT
get job metrics	Get job metrics	GET

Note

get job logs, get job documentation, proxy requests, get job config, update job config, and get job metrics are available only while the job is running. Jobs have their own API endpoints like lambdas, but they respond only while the job is running.