Developer Overview
Use this section when you are maintaining CBIcall itself: adding workflows, editing the workflow registry, or declaring resource entries. Normal users usually only need the Run, Pipelines, and Reproducibility sections.
CBIcall can be extended in two main ways:
Add a Pipeline
Add a Bash or Snakemake entrypoint and register it in the workflow registry, workflows/registry/workflows.yaml. Users can then select it from the parameters YAML.
Add a Resource
Add a resource catalog entry that declares which workflow keys it supports and how installed resource identity can be checked.
What Extension Means
Extending CBIcall does not usually mean changing the Python execution driver. For most additions, the stable contract is:
| Extension point | Main file | Purpose |
|---|---|---|
| Workflow registry | workflows/registry/workflows.yaml | Developer-facing file that declares available workflow implementations. |
| Workflow scripts | workflows/bash/... or workflows/snakemake/... | Implement the actual analysis steps. |
| Resource catalog | resources/cbicall-resource-catalog.json | Declares external resource compatibility and identity metadata. |
| Parameters YAML | user-provided *.yaml | Selects one registered workflow and resource for a run. |
Python changes are usually needed only when introducing a new execution model, a new top-level parameter, or a new compatibility rule.
Where To Start
- To add a workflow implementation, start with Adding a Pipeline.
- To add a reference/tool resource set, start with Adding Resources.
- To understand how the pieces connect, start with Architecture.
After editing the workflow registry or resource files, run the relevant checks:
bin/cbicall validate-registry
bin/cbicall validate-resources
bin/cbicall validate-param -p parameters.yaml
validate-registry is mainly for pipeline developers. It checks that CBIcall's
workflow registry is structurally valid; it does not run a workflow.