DBOS CLI

[maxdml]

• Add a CLI for workflow management and convenient start/migrate/postgres utilities
• Update releaser program such that it 1) compiles the CLI against a few common architectures and 2) attach these as assets to the release

Usage

CLI installation

• Manually by downloading the asset from github
• Running go install github.com/dbos-inc/dbos-transact-golang/cmd/dbos (note that the version, e.g. @latest, has to be specified if running go install outside of a go project)

Example (go install and local dev build)

Output format

The CLI has a global --json flag, e.g.:

Notes

• reset destroy / recreates the target database, but does not perform any migration. Migrations will be applied next time a DBOS context is created against that database.
• init bootstraps a dbos-toolbox application

[kraftp]

This look good--how did we decide to handle inputs and outputs? Based on yesterday's discussion, I think the best option is for the client (and therefore the CLI) to not return any serialized values.

This is a problem for getEvent and eventually readStream as they do nothing else—can we document the need to register non-standard output types for them specifically?

[kraftp]

Large and good PR, so okay to merge after smaller fixes. We can fix serialization in another PR.

[maxdml]

This look good--how did we decide to handle inputs and outputs? Based on yesterday's discussion, I think the best option is for the client (and therefore the CLI) to not return any serialized values.

This is a problem for getEvent and eventually readStream as they do nothing else—can we document the need to register non-standard output types for them specifically?

I modified this PR to have the calls to ListWorkflows not load the input/outputs.

I need to think a bit about the client -- right now a few methods do load input/output by default (e.g., RetrieveWorkflow and the handles' GetStatus). To maintain the simple interface we have, I think we can have these disable loading if the context hasn't been launched (== its a client)

With respect to documentation, I'll add that. Generally speaking workflow/step input/outputs have to be "serializable" in the Golang sense, that is, they must be publicly exported. This is because all go encoders use reflection under the hood (and private fields are not, by default, visible to the Reflect package (albeit backdoors exist but are documented as unsafe)