Tap.Studio.Cli 0.7.0-p.2

tap-studio

Run Tap workspace requests, flows, and test sets from a terminal or from CI.

Same engine as Tap Studio's UI, so a verdict here and a verdict there are the same computation — not two implementations that drift.

dotnet tool install --global Tap.Studio.Cli
tap-studio test "Demo API smoke"

Commands

<name> is a workspace-relative path, the name: from the file's frontmatter, or its filename stem — whichever you have to hand. tap-studio test --list shows what's available.

Select more than one at a time, or less than all of one:

tap-studio test --tag smoke                  # every test set and flow tagged smoke
tap-studio test --tag smoke --tag graphql    # either tag — repeated tags union
tap-studio test "Order API" --filter refund  # only the tests whose name contains "refund"

A selection matching nothing exits 2 rather than reporting a green run over zero tests.

The workspace is found by walking up from the working directory to the nearest workspace.tap, the way git finds a repo. --workspace <dir> overrides it.

Input variables

tap-studio test "Order API" --var customer=cus_ci --var sku=ABC-1
tap-studio test "Order API" --var-file ci.env --var-file overrides.json

These land above every file scope, so they beat whatever the environment or the request declares. Later --var-files win over earlier ones; --var beats all of them.

In CI

- run: dotnet tool install --global Tap.Studio.Cli
- run: tap-studio test "Demo API smoke" --env ci --output junit --output-file results.xml
  env:
    TAP_SECRETS_ALLOWED: "DEMO_*_TOKEN"      # the env provider's allowlist
    DEMO_API_TOKEN: ${{ secrets.DEMO_API_TOKEN }}

--output takes junit, trx, json, or markdown. JUnit is read by GitHub Actions, GitLab, Azure DevOps, and Jenkins without a plugin; markdown is for the places a human reads.

- run: |
    tap-studio test --tag smoke --output markdown --output-file summary.md
    cat summary.md >> "$GITHUB_STEP_SUMMARY"

The Markdown report leads with failures in full, then a table per target. Passing targets collapse into a <details>; failing ones stay open.

Exit codes

1 versus everything above it is the distinction that matters: a red build because an API misbehaved is not the same situation as a red build because the runner couldn't do its job.

Authentication

Profiles that need a runtime token are handled without a browser:

An interactive grant fails immediately with exit 4 and a message naming the profile and the alternatives, rather than blocking the job on a sign-in prompt nobody can see.

The developer token cache at ~/.tap/auth-tokens.json is not consulted unless you pass --use-cached-tokens. A CI run that passes because someone's laptop had a warm token is a test that didn't really run.

Related packages

• Tap.Execution — the engine, if you want to embed it.
• Tap — the separate Tap Tunnels CLI, with inspection built in. Different product and command; both can be installed side by side.

Full documentation: docs/studio.md.