Execution policy¶

Configure queue priorities, launcher capabilities, and retry windows through Helm values. These controls affect workflow execution, not GitLab project access.

Priorities¶

configs:
  additional_ogc_inputs:
    prefix_input: "antflow_config:"
    priorities:
      Low: 3
      Medium: 2
      High: 1

The server adds an optional antflow_config:priority input to process descriptions. Users select one of the configured labels, and the server stores its numeric value on the job. Lower numbers run first. By default, launchers request queued jobs ordered by priority ascending, then creation time ascending; a launcher requesting another sort order can override this ordering. Priority does not preempt running jobs.

Keep the input prefix stable: changing it changes the names expected by API clients. For example, an execution request can include:

{
  "antflow_config:priority": "High"
}

Include the workflow's required inputs in the same execution content. For dynamic process requests, place this value inside the execution_content object alongside the request's cwl and env fields.

Launcher capabilities¶

Launchers advertise supported_flavors, such as gpu or high-memory. A workflow can request capabilities through a FlavorInfo hint:

class: Workflow
hints:
  - class: FlavorInfo
    flavors: [gpu, high-memory]

This is a fragment of a workflow definition, not a Helm value. A launcher must advertise all requested flavors to be eligible. Labels do not allocate GPUs or memory by themselves: configure the runner and its infrastructure accordingly.

Eligible launchers must also be accessible to the user, have an unexpired token, and have contacted the server within configs.launcher.ttl seconds (default 86400). The process description exposes a launcher selector for eligible launchers. If none satisfies the requirements, workflow submission is rejected. Check group claims, launcher availability, token expiry, and flavor labels when diagnosing this error.

Job retries¶

configs:
  retry_ttl: 86400

The default retry window is one day after a failed job finishes. Set it to 0 to disable the retry window. A retry uses the same job ID and execution content; it is not a new submission with edited inputs.

Clients request a retry with POST /jobs/{job_id}/retry, relative to the configured API base URL. The job must be failed and still inside the configured window. Otherwise, the API returns HTTP 400. Job responses include can_retry, which the UI uses to enable the Retry action. Normal job-access permissions still apply.

A retry puts the job back into the accepted state and clears its start/finish timestamps. If it was assigned to a launcher, the retry targets that launcher again. Check the launcher's availability before retrying.

API inspection and sorting¶

Follow Access the API to set API_URL, load your credential into TOKEN, and open the deployed server's interactive reference. Use the same Bash session for the read-only inspection below.

For endpoints supporting order_by, each query value is a JSON object specifying the column, direction (ASC or DESC), and sorting precedence. Repeat the query parameter for multiple sort keys. For example:

curl --fail --silent --show-error --get "$API_URL/jobs" \
  --header "Authorization: Bearer $TOKEN" \
  --data-urlencode 'order_by={"column":"created","direction":"DESC","order":"1"}' \
  --data-urlencode 'limit=20'

Use columns supported by the endpoint; consult its API documentation rather than assuming every job field can be used for sorting.