Summary
tool-runner should detect and use gotap when available in container images, mirroring the plan for gorun (see tool-spec/gorun#3). When gotap is present, invoke it for execution to benefit from its validation and metadata capabilities. Otherwise, fall back to the current direct CMD execution.
Current State
- Spec discovery:
cat /src/tool.yml in a throwaway container
- Execution: Starts container with image default CMD; no command override
- Input: Writes
inputs.json with parameters + data (aligned with current spec)
- Environment: Sets
TOOL_RUN=tool.name for legacy templates
- gotap usage: None
High-Level Plan
Goal: If gotap is detected inside the container, use it for execution. Otherwise, keep current behaviour.
Phase 1: Probe for gotap
Before running a tool, probe the container:
- Create a short-lived container from the image
- Run
gotap --version (or which gotap if no version flag exists)
- Exit code 0 = gotap present
Implementation notes:
- New function in
toolbox_runner/: probe_gotap(docker_client, image_name) -> bool
- Probe could run:
client.containers.run(image, command="command -v gotap || which gotap || true", remove=True) and check stdout
Phase 2: Dual execution paths in runner.run()
In toolbox_runner/runner.py:
- Call probe before creating the run container
- If gotap found: override the run to use gotap as entrypoint
command="gotap run <tool_name> --input-file /in/inputs.json" (or equivalent docker-py syntax)
- If gotap not found: keep current behaviour (no command override, image CMD)
Input file: tool-runner already writes inputs.json with the correct format. Pass --input-file /in/inputs.json when invoking gotap.
Tasks Checklist
Reference
Summary
tool-runner should detect and use gotap when available in container images, mirroring the plan for gorun (see tool-spec/gorun#3). When gotap is present, invoke it for execution to benefit from its validation and metadata capabilities. Otherwise, fall back to the current direct CMD execution.
Current State
cat /src/tool.ymlin a throwaway containerinputs.jsonwith parameters + data (aligned with current spec)TOOL_RUN=tool.namefor legacy templatesHigh-Level Plan
Goal: If gotap is detected inside the container, use it for execution. Otherwise, keep current behaviour.
Phase 1: Probe for gotap
Before running a tool, probe the container:
gotap --version(orwhich gotapif no version flag exists)Implementation notes:
toolbox_runner/:probe_gotap(docker_client, image_name) -> boolclient.containers.run(image, command="command -v gotap || which gotap || true", remove=True)and check stdoutPhase 2: Dual execution paths in runner.run()
In
toolbox_runner/runner.py:command="gotap run <tool_name> --input-file /in/inputs.json"(or equivalent docker-py syntax)Input file: tool-runner already writes
inputs.jsonwith the correct format. Pass--input-file /in/inputs.jsonwhen invoking gotap.Tasks Checklist
probe_gotap(client, image_name) -> bool(or usegotap --versionwhen added to gotap)runner.run()on probe result["gotap", "run", tool_name, "--input-file", "/in/inputs.json"]/outmount exists (already the case) for gotap metadata outputReference