Local vs cloud
The SDK is the same in both places. The decision is about what runs the tests — your laptop, a hosted Roboticks runner, or one you operate yourself.At a glance
Local: pytest and colcon as you know them
Nothing about the SDK forces a runner. Run pytest the way you always have:@confirms decorators still take effect — the pytest plugin still writes properties into the JUnit XML — but no one is uploading that XML to the platform. The local run is for the inner loop: write code, run tests, iterate.
Cloud: rbtk test cloud
rbtk test cloud is the “skip the PR loop” command. It bundles your working tree (including dirty files), uploads to the platform, runs on a hosted runner of the right shape, and streams logs back to your terminal in real time.
Output:
GitHub PR: the default cloud path
When the GitHub App is installed on a repo, every PR automatically runs the test suite on a hosted (or self-hosted, by routing label) runner. The Check Run posts back to the PR with a coverage delta. This is the normal mode of operation. You don’t runrbtk test cloud for the PR loop. You run it for between-PR experiments: trying a fault-injection scenario that needs sim minutes you don’t have locally, or asking “does this branch break REQ-014?” without the overhead of opening a draft PR.
Auth flows
Decision matrix
What never changes
@confirms,@tags,@deadline,@requires_simproduce the same JUnit XML wherever they run.- The wire contract is the same wherever they run.
- The matrix doesn’t care whether a test ran locally-uploaded, via
rbtk test cloud, via PR, or via a self-hosted runner — only that the commit SHA is recorded.
Next
CLI: test commands
Full surface of
rbtk test cloud, results, upload, retry.Sim runners
When
--sim gazebo matters and what it costs.GitHub App
How the PR loop produces a Check Run.
Self-host a runner
Bring your own compute, no sim-minute charges.