Self-service pipeline (SSP) artifacts (protocols and task scripts, or Tetraflows) can include an optional manifest.json file that contains metadata, configuration, and specifications for each artifact. When present, the manifest.json file serves as the source of truth for each artifact's metadata and tells the Tetra Data Platform (TDP) how to discover, deploy, and display each artifact in the user interface.

📘

NOTE

After you create a manifest.json file for your artifact, you don't need to specify any of the required configuration fields in your ts-cli publish command arguments. The command pulls the required artifact configuration fields from each artifact's manifest.json file automatically if one is present in the artifact's root directory. For more information, see the Hello, World! SSP Example.

SSP manifest.json Examples

Minimum manifest.json File Example

The following is an example of a basic SSP protocol manifest.json file, which includes only the required fields:

{
  "type": "protocol",
  "namespace": "private-my-org",
  "slug": "data-processing-pipeline",
  "version": "v1.0.0"
}

Recommended manifest.json File Example

While only four fields are required, it's recommended to include additional, optional metadata for better documentation and discoverability:

{
  "type": "protocol",
  "namespace": "private-my-org",
  "slug": "data-processing-pipeline",
  "version": "v1.0.0",
  "name": "Data Processing Pipeline",
  "description": "A self-service pipeline for processing and transforming laboratory data",
  "catalog_keys": ["any"],
  "labels": [
    {
      "name": "category",
      "value": "data-processing"
    },
    {
      "name": "environment",
      "value": "dev"
    }
  ]
}

SSP Artifact Manifest Fields

SSP artifact manifest.json files include the following required and optional fields.

Required Fields

Optional Fields

Validation Rules

General Validation

• Validation only occurs if a manifest.json exists
• Missing files cause publishing to fail
• name (optional): Cannot be empty, should match the title of the readme file
• namespace (required): Should be private, appeneded with a hyphen (-) and your target orgSlug (format: private-{orgslug/orgslugprefix})
• slug (required): Must be an alphanumeric string (slug)that serves as a unique identifier for the artifact (for example: akta-raw-to-ids)
• version (required): Must match versions in pyproject.toml, README.md, and schema.json (for IDS)
• description (optional): Cannot be empty
• type (required): Must be valid artifact type
• icon (optional): If present, must equal "images/icon.png", file must exist, and be under 512 KB
• labels (optional): Can be empty array, objects must have name and value fields

Restricted Label Names

The name field in labels cannot be any of the following:

• catalog_key
• instrument_type
• instrument_model
• vendor
• software
• software_version

Best Practices

When configuring SSP artifact manifest.json files, keep in mind the following best practices:

• Include descriptive metadata: Even though optional, name and description help with artifact discovery
• Use meaningful labels: Add labels that help categorize and search for your SSP
• Follow semantic versioning: Use proper version format (v1.0.0) for better version management
• Set appropriate catalog keys: Use "any" if no specific catalog integration is needed
• Document dependencies: Use the description field to note any external dependencies or requirements