Build & verify
Seven tools that prove a change works before anyone looks at it.
Every tool here takes _workspace, _sandbox and _toolchain — bind all three. Without a toolchain there is no command to run, and the tool says so. See Filling in tool parameters.
The commands are yours. Each tool runs whatever your Code Toolchain configures for it. dotnet build, npm run build, mvn package and an in-house script are the same code path — which is why a new language needs no platform release.
The five checks
code_build, code_test, code_lint, code_typecheck and code_security_scan all take the same parameters and differ only in which configured command they run.
| Parameter | Kind | Notes |
|---|---|---|
command | Pin | Run this exact command instead of the toolchain’s. Overrides for this agent only. |
working_dir | Pin | Sub-directory to run in. Omit to use the toolchain’s. |
timeout_seconds | Pin | Omit to use the toolchain’s, then the sandbox’s. Raise for a cold restore. |
restore | Agent fills | (build and test only) Runs the configured restore command first, if there is one. |
code_build
Compile the project. Category: Action. Errors come back parsed, with file and line, rather than as raw output — that is what Stack on the toolchain is for.
code_test
Run the test suite and report pass/fail counts with the individual failures. Category: Action.
Set Test report path on the toolchain. A .trx or JUnit XML file is read as ground truth; scraping output is the fallback and is less reliable.
code_lint · code_typecheck · code_security_scan
Run the project’s linter, type checker or security scanner and return parsed findings. Category: Action.
Each one needs its command configured on the toolchain. Leave the command blank and the tool returns a refusal saying so — and its check is skipped by the quality gate.
command_run
Run one permitted command inside the working copy, for anything the five above do not cover. Category: Action.
- The agent fills:
command— the executable alone, e.g.dotnet - The agent fills:
args— one argument per element, never one joined string - Pin:
working_dir,timeout_seconds,env
There is no shell. The command is [executable, ...args] handed straight to the operating system, which removes command injection as a category. It also means args must be a list — ["test", "--filter", "Cat=Fast"], not "test --filter Cat=Fast". The executable must be in your Command Sandbox’s allowed commands. env is not for secrets — bind those on the tool.
Prefer the specific tools where they fit. They parse their output into structured findings; this one does not.
code_quality_gate
Run the project’s definition of done and return one verdict. Category: Action.
- Bind:
_quality_gateas well as the three above - The agent fills:
skip— e.g.["security"]to skip a check for this run
This is the tool to run before opening a pull request. When it fails it names the next action to take rather than only reporting numbers.
Checks are derived, not listed. A check runs when the toolchain has a command for it. There is no “which checks” setting, because asking for a lint check with no lint command could only be a mistake. Thresholds come from your Code Quality Gate configuration.
Common issues
- “No build command is configured for this project” — No toolchain is bound, or it has no command for this tool and the stack has no default.
- “Command execution is not configured for this project” — The Command Sandbox is still Disabled.
- A command is refused as not permitted — The executable is not in the sandbox’s allowed commands. Add it, with the policy set to allow additions.
- A build times out — Raise
timeout_seconds, or the toolchain’s build timeout. A cold restore on a large solution can exceed ten minutes. - Test counts look wrong — No Test report path is set, so the counts are scraped from output. Set it.
- The gate passes but a check you expected did not run — Its command is not configured on the toolchain, so the gate skipped it.