Piotr Sarnacki
4c962b9170
# Description of Changes
This PR implements support for the `spacetime.json` configuration file
that can be used to set up common `generate` and `publish` targets. An
example of `spacetime.json` could look like this:
```
{
"dev_run": "pnpm dev",
"generate": [
{ "out-dir": "./foobar", "module-path": "region-module", "language": "c-sharp" },
{ "out-dir": "./global", "module-path": "global-module", "language": "c-sharp" },
],
"publish": {
"database": "bitcraft",
"module-path": "spacetimedb",
"server": "local",
"children": [
{ "database": "region-1", "module-path": "region-module", server: "local" },
{ "database": "region-2", "module-path": "region-module", server: "local" }
]
}
}
```
With this config, running `spacetime generate` without any arguments
would generate bindings for two targets: `region-module` and
`global-module`. `spacetime publish` without any arguments would publish
three modules, starting from the parent: `bitcraft`, `region-1`, and
`region-2`. On top of that, the command `pnpm dev` would be executed
when using `spacetime dev`.
It is also possible to pass additional command line arguments when
calling the `publish` and `generate` commands, but there are certain
limitations. There is a special case when passing either a module path
to generate or a module name to publish. Doing that will filter out
entries in the config file that do not match. For example, running:
```
spacetime generate --project-path global-module
```
would only generate bindings for the second entry in the `generate`
list.
In a similar fashion, running:
```
spacetime publish region-1
```
would only publish the child database with the name `region-1`
Passing other existing arguments is also possible, but not all of the
arguments are available for multiple configs. For example, when running
`spacetime publish --server maincloud`, the publish command would be
applied to all of the modules listed in the config file, but the
`server` value from the command line arguments would take precedence.
Running with arguments like `--bin-path` would, however, would throw an
error as `--bin-path` makes sense only in a context of a specific
module, thus this wouldn't work: `spacetime publish --bin-path
spacetimedb/target/debug/bitcraft.wasm`. I will throw an error unless
there is only one entry to process, thus `spacetime publish --bin-path
spacetimedb/target/debug/bitcraft.wasm bitcraft` would work, as it
filters the publish targets to one entry.
# API and ABI breaking changes
None
# Expected complexity level and risk
3
The config file in itself is not overly complex, but when coupled with
the CLI it is somewhat tricky to get right. There are also some changes
that I had to make to how clap arguments are validated - because the
values can now come from both the config file and the clap config, we
can't use some of the built-in validations like `required`, or at least
I haven't found a clean way to do so.
# Testing
I've added some automated tests, but more tests and manual testing is
coming.
---------
Signed-off-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
Co-authored-by: bradleyshep <148254416+bradleyshep@users.noreply.github.com>
Co-authored-by: clockwork-labs-bot <clockwork-labs-bot@users.noreply.github.com>
Co-authored-by: = <cloutiertyler@gmail.com>
Co-authored-by: Tyler Cloutier <cloutiertyler@users.noreply.github.com>
SpacetimeDB's cargo ci
Overview
This document provides an overview of the cargo ci command-line tool, and documentation for each of its subcommands and options.
cargo ci
SpacetimeDB CI tasks
This tool provides several subcommands for automating CI workflows in SpacetimeDB.
It may be invoked via cargo ci <subcommand>, or simply cargo ci to run all subcommands in sequence. It is mostly designed to be run in CI environments via the github workflows, but can also be run locally
Usage:
Usage: cargo ci [OPTIONS] [COMMAND]
Options:
--skip: Skip specified subcommands when running all
When no subcommand is specified, all subcommands are run in sequence. This option allows specifying subcommands to skip when running all. For example, to skip the unreal-tests subcommand, use --skip unreal-tests.
--help: Print help (see a summary with '-h')
test
Runs tests
Runs rust tests, codegens csharp sdk and runs csharp tests. This does not include Unreal tests. This expects to run in a clean git state.
Usage:
Usage: test
Options:
--help: Print help (see a summary with '-h')
lint
Lints the codebase
Runs rustfmt, clippy, csharpier and generates rust docs to ensure there are no warnings.
Usage:
Usage: lint
Options:
--help: Print help (see a summary with '-h')
wasm-bindings
Tests Wasm bindings
Runs tests for the codegen crate and builds a test module with the wasm bindings.
Usage:
Usage: wasm-bindings
Options:
--help: Print help (see a summary with '-h')
dlls
Builds and packs C# DLLs and NuGet packages for local Unity workflows
Packs the in-repo C# NuGet packages and restores the C# SDK to populate sdks/csharp/packages/**. Then overlays Unity .meta skeleton files from sdks/csharp/unity-meta-skeleton~/** onto the restored versioned package directory, so Unity can associate stable meta files with the most recently built package.
Usage:
Usage: dlls
Options:
--help: Print help (see a summary with '-h')
smoketests
Runs smoketests
Executes the smoketests suite with some default exclusions.
Usage:
Usage: smoketests [OPTIONS] [ARGS]... [COMMAND]
Options:
--server: Run tests against a remote server instead of spawning local servers.
When specified, tests will connect to the given URL instead of starting local server instances. Tests that require local server control (like restart tests) will be skipped.
--dotnet:args:--help: Print help (see a summary with '-h')
prepare
Only build binaries without running tests
Use this before running cargo test --all to ensure binaries are built.
Usage:
Usage: prepare
Options:
--help: Print help (see a summary with '-h')
help
Usage:
Usage: help [COMMAND]...
Options:
subcommand:
update-flow
Tests the update flow
Tests the self-update flow by building the spacetimedb-update binary for the specified target, by default the current target, and performing a self-install into a temporary directory.
Usage:
Usage: update-flow [OPTIONS]
Options:
--target: Target triple to build for, by default the current target. Used by github workflows to check the update flow on multiple platforms.--github-token-auth: Whether to enable github token authentication feature when building the update binary. By default this is disabled.--help: Print help (see a summary with '-h')
cli-docs
Usage:
Usage: cli-docs [OPTIONS]
Options:
--spacetime-path: specify a custom path to the SpacetimeDB repository root (where the main Cargo.toml is located)--help: Print help (see a summary with '-h')
self-docs
Usage:
Usage: self-docs [OPTIONS]
Options:
--check: Only check for changes, do not generate the docs--help: Print help (see a summary with '-h')
global-json-policy
Usage:
Usage: global-json-policy
Options:
--help:
help
Usage:
Usage: help [COMMAND]...
Options:
subcommand:
This document is auto-generated by running:
cargo ci self-docs