Skip to content

Application packages

An application package brings together a workflow definition, its referenced tools and files, and the runtime image references needed to execute it. AntFlow uses CWL-based packages following the OGC Application Package specification.

For the publication procedure, follow Publish a workflow.

Package contents

Keep these files in the GitLab repository:

  • A valid CWL document with cwlVersion and a class: Workflow definition.
  • All referenced CWL tools and supporting package files.
  • A README.md describing the project, inputs, and outputs, recommended for project presentation.
  • Dockerfiles and build sources for runtime images you maintain, when applicable.

Declare input and output types explicitly. Use CWL label and doc fields to describe the process and its parameters; the project README does not replace those process-level descriptions. See the CWL reference.

The examples in this guide use CWL v1.2. Supported versions and extensions depend on the runner used by your launcher. Validate the definition and test the workflow on each target environment before publication.

Project documentation and preview

AntFlow uses the README for project documentation. Project cards use the project name and description supplied by the server, with README text as a description fallback. A README is not required for workflow discovery.

To supply a preview image, add a Markdown image whose alt text is preview:

![preview](./assets/preview.png)

Commit the image and README together. Use a repository-relative image path or a reachable Git image URL. Supported formats are .png, .jpg, and .jpeg. The server supplies the selected image as a preview link; the UI displays it when retrievable and otherwise uses its default card background.

Container portability

Put processing scripts, binaries, and dependencies in the runtime image. Do not assume that files from your development machine will be mounted by the launcher. Declare the executable using CWL baseCommand rather than relying solely on a Docker ENTRYPOINT, whose handling can differ between runners.

Kubernetes

  • Include /bin/sh for shell-based runtime invocation.
  • Ensure the execution environment can reach the image registry and has any required pull credentials.
  • Make each DockerRequirement.dockerPull reference match a published image.

HPC with Singularity

Runtime images may need conversion to SIF files and provisioning in an image cache. The cache location and filename mapping are deployment-specific; confirm them with the administrator. Do not assume a universal naming convention.

See Check the execution environment for pre-publication checks and the Toil / Slurm guide for launcher setup.

Access and execution configuration