See Job processing design for the processing
architecture, job execution flow, Slicer CLI registration guidance, and the
category scoping that keeps VolView tasks separate from HistomicsUI and
DIVE-DSA tasks in a shared slicer_cli_web deployment.
Publish custom task images to a container registry and list immutable versions
under slicer-cli-image in the DSA provision YAML. See
Building and deploying custom Slicer CLIs
for the complete workflow, including private registries.
The development stack uses the
VolView Radiology CLI as
reference infrastructure to drive and test the processing backend. Clone it
locally and set CLI_REPO in this repository's .env to that checkout:
git clone https://github.com/PaulHax/volview-radiology-cli
# In girder_volview/.env:
CLI_REPO=/path/to/volview-radiology-cliWhen processing routes are present, script/deploy calls
script/ensure-radiology-cli. That script builds the local
volview-radiology-cli:latest image if it is missing, registers it with
slicer_cli_web, and verifies the declared tasks are available. It does not
pull this image from a registry.
The VolView plugin proxies request to download files from S3 by default. This avoids a CORS error when loading a file from an S3 bucket asset store without CORS configuration. To speed up downloading of files from S3, the Girder admin can:
- Configure CORS in the S3 bucket for the Girder server.
- Change the global Girder configuration to add
a
[volview]section with aproxy_assetstores = Falseoption. See below:
[volview]
# Workaround CORS configuration errors in S3 assetstores.
# If True, the Girder server will proxy file download requests from
# VolView clients to the S3 assetstore. This will use more server bandwidth.
# If False, VolView client requests to download files are redirected to S3.
# Defaults to True.
proxy_assetstores = False