Run Tests

Run Tests

Run the Bactopia nf-test suite through bactopia-test for a specific component and present the live output to the user. This is the "before" half of the run-tests / review-tests pair: this skill runs the tests and writes a timestamped logs/run-tests/{timestamp}/ directory; /review-tests then interprets that directory (grouping failures, reading stdout files, etc.). Keep the two responsibilities clearly separated -- do not try to do /review-tests' job here.

Every run is a 4-profile matrix. bactopia-test no longer takes a --profile flag. For each selected component it tests docker, conda, singularity_galaxy, and singularity_pull: docker validates (or generates) the snapshot and the other three validate against it, surfacing runtime drift without rewriting tests. Conda envs and Singularity images are pre-built serially (from --cachedir) before the parallel test phase, so even a single-component run pays that build/setup cost up front.

Steps

1. Resolve --tier and --include from what the user said. Use the "Resolving arguments" table below. If the user did not name a specific component, stop and ask which component they want to test -- do not run the full suite (see the guardrails block).

2. Invoke the wrapper script with the resolved arguments:

   bash .agents/skills/run-tests/scripts/run-bactopia-test.sh \
       --bactopia-path /home/rpetit3/repos/bactopia/bactopia \
       --test-data /home/rpetit3/repos/bactopia/bactopia-tests \
       --outdir /home/rpetit3/repos/bactopia/bactopia \
       --cachedir /data/cache \
       [--tier TIER] \
       --include COMPONENT

   Omit --tier entirely when the user said "test snippy" (no tier hint) -- the CLI's default all will then search every tier and the underscore- segment matcher (see "--include matching") will pick up every component whose name contains snippy.

3. Present the CLI's live output directly. bactopia-test produces a Rich table with per-component, per-profile status (docker / conda / singularity_galaxy / singularity_pull), durations, and a final summary. Relay it without reformatting. Do not parse JSON, do not re-tabulate, do not read the stdout files the CLI writes.

4. After the run finishes, extract the run timestamp and hand off to /review-tests. See the "After the run" section.

Resolving arguments (tier inference)

bactopia-test's --include matcher is exact-match OR underscore-segment match against a flattened component name (e.g. modules/snippy/run/tests/main.nf.test → snippy_run). Patterns and wildcards are not supported. That means --include snippy matches snippy_run, snippy_core, etc.; --include snippy_run matches only the module.

Translate user phrasing into flags as follows:

If the user's request is ambiguous (e.g. "test snippy" could mean the module, the subworkflow, or both), omitting --tier is the safe default -- the segment matcher will catch all three and the user sees everything at once.

Defaults the skill applies automatically

These flags are always added without asking the user:

When to ask the user first (never auto-fill)

Important Reminders

These are the non-negotiable rules. Violating any of them can burn hours of time or delete work the user cares about.

• CRITICAL: never run with no component filter. With no --include, the CLI tests every component (250+ across modules, subworkflows, and workflows) and each one runs the full 4-profile matrix -- plus a serial env pre-build phase. That is very expensive and is not what this skill is for. If the user asks to "run tests" without naming a component, stop and ask which module / subworkflow / workflow they want.

• NEVER pass --generate unless the user explicitly asked for it with the literal flag name or the phrases "generate mode", "regenerate snapshots", or "update snapshots". --generate forces regeneration of the docker snapshot, overwriting the committed .snap for the tested components. (Without it, a missing snapshot is still generated automatically; an existing one is validated, not touched.)

• ALWAYS pass --cachedir /data/cache. The pre-built conda/ and singularity/ env caches live there on this host. The CLI default (~/.bactopia) is empty, so omitting it forces every environment to rebuild from scratch -- hours of wasted work.

• ALWAYS pass --outdir /home/rpetit3/repos/bactopia/bactopia so that logs/run-tests/{timestamp}/ is written at the bactopia repo root. /review-tests looks for logs relative to --bactopia-path; if --outdir is omitted the logs land in whatever directory the shell was invoked from and the downstream skill will not find them.

• Do NOT pass --json. The default Rich text output is human-friendly and already auto-logs a machine-readable summary.json into the logs directory. --json exists as a fallback for programmatic parsing -- it is not needed here.

• Do NOT pass --fail-fast unless the user explicitly asks. The default "run every component, report all failures at the end" behavior is what /review-tests expects to consume. (--fail-fast stops on the first component with any failing profile.)

• Do NOT interpret failures in detail here. Do not read stdout.txt, stderr.txt, outputs.txt, or nextflow.log files. Do not group failures by type. Do not recommend fixes. That is deliberately reserved for /review-tests so the two skills stay loosely coupled and each has a single clear job.

• There is no --profile flag anymore. Every run tests all four profiles. If the user wants to re-check a single drifting/timed-out profile cell (e.g. "re-run stecfinder's conda test"), you still run the whole component -- the matrix always covers that profile -- and point them at that profile's row in the output.

• A timeout can be an intermittent hang, not a too-small budget -- do not assume raising -tm will let it finish. Per-component timeout = min(expected_seconds * -tm, --timeout). A cell that hangs never completes: the task is killed by SIGTERM at the cap, so a bigger budget only makes it hang longer. Confirmed example: stecfinder's conda profile has repeatedly wedged on its third case -- the task runs the full ~184s (46.1 * 4) and is killed (exit 143, succeededCount=0; abortedCount=1, no Task completed, 0-byte outputs), yet the whole component passes in ~24s (docker ~24s) when the hang doesn't recur. This is a known intermittent hang to keep an eye on, not slowness and not a baseline problem. When a cell reports timeout, inspect the work tree to classify it, then act:

  • Hang ({profile}/.nf-test/.../work/**/.exitcode = 143, empty/0-byte outputs, no Task completed in meta/nextflow.log): the tool/task never returned control to nextflow/nf-test. Do NOT raise -tm or --update-baselines -- neither addresses a hang. In a real pipeline run Nextflow's own task retries absorb an intermittent hang like this, so no code change is required unless it becomes persistent. If it does recur often, escalate to a cross-environment deep dive (compare the docker vs conda vs singularity envs -- program versions, dependency pins) to find what differs on the wedging profile.
  • Genuine slow-but-completes (task reaches COMPLETED just past the budget): re-run with a raised -tm; if it then passes, the budget was the issue. Only this case warrants a baseline/multiplier adjustment.