Creation pipeline
-----------------

.. note::
   Most of the information in the `Lambda documentation <./lambdas.html#creation-and-lifecycle>`_
   also applies to **jobs**, with the exceptions noted in this chapter.

To `create a job
<./_static/api.html#tag/jobs-creation>`_, a **workflow** must
`first be created <./_static/api.html#tag/workflow-creation>`_ or
`imported <./_static/api.html#tag/workflow-importexport/operation/importWorkflow>`_.
A workflow can be created in two ways, similar to `lambda creation <./creation_pipeline.html>`_:
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
<./_static/api.html#tag/workflow-image-monitoring/operation/getWorkflowImageStatus>`_
to check the build status and the `workflow image logs request
<./_static/api.html#tag/workflow-image-monitoring/operation/getWorkflowImageCreationLogs>`_
to retrieve build logs.
Additionally, there is a dedicated `workflow export request
<./_static/api.html#tag/workflow-importexport/operation/exportWorkflow>`_
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 <./workflow_queue.html>`_.

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 <./_static/api.html#tag/jobs-creation/operation/createJob>`_.
Jobs created within a workflow will be deleted when the workflow is deleted
(`delete workflow
<./_static/api.html#tag/workflow-deletion/operation/deleteWorkflow>`_).
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 <./_static/api.html#tag/jobs-deletion/operation/deleteJob>`_)
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 <./workflow_queue.html>`_.

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:

.. list-table:: Job API requests
   :header-rows: 1

   * - Request
     - Description
     - API Reference
   * - get job
     - Get job by ID
     - `GET <./_static/api.html#tag/job-monitoring/operation/getJob>`_
   * - get jobs
     - Get jobs according to filters
     - `GET <./_static/api.html#tag/job-monitoring/operation/getJobs>`_
   * - delete job
     - Remove job by ID
     - `DELETE <./_static/api.html#tag/jobs-deletion/operation/deleteJob>`_
   * - get job logs
     - Get job logs
     - `GET <./_static/api.html#tag/job-monitoring/operation/getJobLogs>`_
   * - get job documentation
     - Get job OpenAPI documentation
     - `GET <./_static/api.html#tag/job-documentation/operation/getJobSpec>`_
   * - Proxy requests
     - Proxy requests to job
     - `POST/GET/HEAD/PUT/PATCH/DELETE <./_static/api.html#tag/job-proxy>`_
   * - get job config
     - Get job config
     - `GET <./_static/api.html#tag/job-config/operation/getJobConfig>`_
   * - update job config
     - Update job config
     - `PUT <./_static/api.html#tag/job-config/operation/putJobConfig>`_
   * - get job metrics
     - Get job metrics
     - `GET <./_static/api.html#tag/job-metrics/operation/getJobMetrics>`_

.. 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.