By default, the dataclip body is not returned via a query. This query selects the body specifically.

@spec filter_log_lines(Ecto.Queryable.t(), map()) :: Ecto.Queryable.t()

Narrows a query of log lines by filters, keyed and typed as log_line_filter_types/0 says.

@spec filter_runs(Ecto.Queryable.t(), map()) :: Ecto.Queryable.t()

Narrows a query of runs by filters, keyed and typed as run_filter_types/0 says.

@spec filter_work_orders(Ecto.Queryable.t(), map()) :: Ecto.Queryable.t()

Narrows a query of work orders by filters, keyed and typed as work_order_filter_types/0 says.

@spec last_step_for_job(Lightning.Workflows.Job.t()) :: Ecto.Queryable.t()

The last step for a job

@spec last_successful_step_for_job(Lightning.Workflows.Job.t()) :: Ecto.Queryable.t()

The last successful step for a job, used in scheduler to enable downstream runs to access a previous run's state

@spec log_line_filter_types() :: %{required(atom()) => Ecto.Type.t()}

The filters filter_log_lines/2 takes, each with its type.

@spec log_lines_for(Lightning.Scope.t()) :: Ecto.Queryable.t()

@spec log_lines_for(Lightning.Projects.Project.t()) :: Ecto.Queryable.t()

Log lines of every project the caller may list (Lightning.Projects.visible_project_ids/1).

@spec run_filter_types() :: %{required(atom()) => Ecto.Type.t()}

The filters filter_runs/2 takes, each with its type.

@spec runs_for(Lightning.Scope.t()) :: Ecto.Queryable.t()

@spec runs_for(Lightning.Projects.Project.t()) :: Ecto.Queryable.t()

Runs of a given project, or of every project the caller may list (Lightning.Projects.visible_project_ids/1).

Returns a dataclip formatted for use as an input state.

Only http_request dataclips are changed, their body is nested inside a "data" key and request data is added as a "request" key.

Like select_as_input/1, but returns body as JSON text string to avoid expensive deserialization to Elixir map (saves ~38x memory amplification).

Dataclips a job can be run against: the ones it has consumed, plus every named dataclip in its project.

A named dataclip is a curated input rather than a trace of a past run, so the result is no longer bounded by the job. The two sources are unioned rather than ORed so each keeps its own index, instead of making dataclips the driving relation on every keystroke of the picker's search.

@spec steps_for(Lightning.Accounts.User.t()) :: Ecto.Queryable.t()

Steps for a specific user

@spec steps_with_reason(Ecto.Queryable.t(), String.t()) :: Ecto.Queryable.t()

The last step for a job for a particular exit reason, used in scheduler

@spec where_step_failed(Ecto.Queryable.t()) :: Ecto.Queryable.t()

Appends exit_reason != "success" to a query of Step.

A step that never finished carries a nil exit_reason, and NULL != 'success' is false in SQL, so it is excluded here too: a step still in flight is not yet a failure.

@spec work_order_filter_types() :: %{required(atom()) => Ecto.Type.t()}

The filters filter_work_orders/2 takes, each with its type.

@spec work_orders_for(Lightning.Scope.t()) :: Ecto.Queryable.t()

@spec work_orders_for(Lightning.Projects.Project.t()) :: Ecto.Queryable.t()

Work orders of a given project, or of every project the caller may list (Lightning.Projects.visible_project_ids/1).