Results and publication¶

Declared workflow outputs are uploaded to the platform's configured S3-compatible storage by the automatic publication step. The platform can also catalog their metadata in STAC. Result publication is separate from publishing a GitLab project.

Find your results¶

Open a successful job's details and follow its result links. API clients can request job results. Available files, catalogs, and visualizations depend on the workflow and deployment.

Do not assume a fixed bucket, filename, or catalog URL. Follow the links provided for that job, and check your platform's retention policy before treating them as permanent references.

Workflows without declared outputs¶

A workflow can run without exposing result files to AntFlow. Declare an empty outputs map on the selected CWL Workflow object, not just on one of its steps:

outputs: {}

AntFlow does not add the automatic publication step to a workflow with no declared outputs. That step therefore uploads no result files to S3 and creates no STAC catalogs. The workflow's steps can still create files; this declaration does not disable uploads performed explicitly by the workflow's own code.

The job still reports its status and progress, and its logs are uploaded by default. The launcher operator can disable job log archiving independently of workflow output publication.

Disabling result publication or job-log uploads does not preserve local files automatically. For local execution, configure file retention separately; see local runtime settings.

Download files¶

Published files are served through GET /data/{job_id}/{file_path} relative to the API base URL, including the deployment's path prefix. Depending on platform configuration, the server either proxies the file or redirects to a presigned S3 URL.

First follow Access the API to set API_URL and TOKEN, then retrieve your job's results. Choose an AntFlow data URL returned for that job, on the instance you selected. Use the provider-specific API token and allow redirects:

read -r -p "AntFlow data URL from the job's results: " RESULT_URL
curl --fail --silent --show-error --location \
  --header "Authorization: Bearer $TOKEN" \
  "$RESULT_URL" --output result-file

Only send your token to your selected AntFlow instance; do not use this authenticated command for third-party viewer links or direct S3 URLs. Do not add --location-trusted: it can forward credentials to another host after a redirect. A presigned URL authorizes access until it expires; treat it as sensitive and do not publish it in logs or docs. If it expires, request a fresh link through AntFlow rather than editing its signature parameters.

Job access is enforced

Ordinary authenticated users can access their own jobs and jobs with no owner. Administrators have broader job access. Knowing a job ID or opening a STAC catalog does not grant permission to protected files.

The server must reach object storage. When downloads redirect, your browser or client must also reach it. Browser viewers may additionally need the deployment's bucket CORS configuration.

STAC catalogs¶

STAC describes outputs as items with assets. Catalog publication can target:

A dynamic STAC API: a transactional catalog configured by the platform, generally with process collections containing job items.
A static catalog: JSON catalog and item files uploaded to object storage and accessible through AntFlow's data URLs.

An instance can enable either or both. Neither is guaranteed for every job. Disabling STAC cataloging does not by itself disable uploading output files. Protected static catalogs and their assets require authenticated access; the visibility of a dynamic STAC service depends on that service's configuration.

For platform settings, see Publish results to STAC.

Workflow publication properties¶

Declare these properties on your CWL workflow, alongside class, inputs, outputs, and steps. In a packed document, declare them on the selected Workflow object inside $graph. They are not execution inputs, entries under hints, or Helm settings. The examples use the default publish prefix; the administrator controls that prefix through the server's publication configuration.

Property	Effect
`publish:enabled: false`	Skip the automatic publication step, including its S3 output uploads and STAC cataloging. Defaults to `true` when absent.
`publish:catalog: false`	Skip remote STAC API publication while retaining S3 output uploads. Defaults to `true` when absent, but cannot enable a target disabled by the administrator.
`publish:catalog_static: true`	Request static STAC catalog generation in S3. Defaults to `false` when absent. A workflow's `false` value cannot disable static cataloging enabled by the administrator.

For example, these workflow properties express keeping output uploads while opting out of remote STAC API publication:

publish:enabled: true
publish:catalog: false

This does not opt out of administrator-enabled static STAC cataloging. Disabling cataloging is not the same as disabling output archiving.

Catalog services and storage must still be configured by the administrator. Coordinate changes with them and test the workflow's results before sharing it.

STAC metadata¶

Workflow metadata can add properties to generated items:

publish:stac:
  properties:
    software: "my-processor 1.0.0"

Link and asset templates can use file_regex to match published paths. Links without a regex are added directly; regex-based links are generated only when an asset matches. Templates can refer to the matched path using {0}, its archive URL using {0:url}, its archive path using {0:url-path}, or its name using {0:name}. Asset templates with file_regex are expanded for matching files rather than added unconditionally.

Use links to real services available to your users. A template does not create a viewer or archive-download service.

Workflow-provided items¶

A workflow can produce a STAC item alongside a product directory. The publisher looks for its configured item filename, normally stac-item.json, and merges that item's metadata with the generated publication metadata and access links. Confirm the expected filename with your administrator and validate the final published item, not just the item written by the workflow.

Select your own output storage¶

On instances with Keycloak user secrets, a valid vault entry whose alias starts with s3: can make an output-storage choice available in the process description. For example, name the entry s3:myStorage and store an encrypted JSON value with the following structure:

{
  "endpoint_url": "https://s3.example.com",
  "bucket_name": "my-bucket",
  "access_key_id": "<access-key-id>",
  "secret_access_key": "<secret-access-key>",
  "root_dir": "antflow-data",
  "region_name": "us-east-1"
}

Replace the example values with your provider's settings; root_dir and region_name are optional. Store the real JSON through your approved vault procedure, not in Git or a reusable input file.

Select the alias in the process's publication-storage input, normally named antflow_config:s3. If the choice is absent, check the vault entry's name and JSON structure with your administrator. The process description is authoritative for the input name and available aliases.

The bucket must already exist. Both the server's result-access path and the publication environment need connectivity and appropriate permissions; an endpoint reachable only from your computer is insufficient. Keep the bucket and credentials available while jobs still refer to their stored results.