Command Line Interface

Obelisk Server

Running the Server

obelisk server run

Following optional options can be provided:

• --clean-sqlite-directory - Clean the sqlite database directory
• --clean-cache - Clean the codegen and OCI cache directories
• --clean-codegen-cache - Clean the codegen cache directory
• -c, --config <CONFIG> - Path to the TOML configuration

If the -c switch is not provided, Obelisk attempts to find the TOML configuration automatically in the following paths:

1. obelisk.toml in the current directory
2. $CONFIG_DIR/obelisk/obelisk.toml - See Path Prefixes
3. /etc/obelisk/obelisk.toml

Verifying the Server Configuration

Instead of running the server one might wish just to verify the TOML configuration. This includes:

• downloading artifacts from OCI registries
• compiling WASM into the codegen_cache directory
• verifying that all imports are satisfied
• verifying that environment variables required by activities are present (can be disabled)

obelisk server verify [OPTIONS]

Following optional options can be provided:

• --clean-cache - Clean the codegen and OCI cache directories
• --clean-codegen-cache - Clean the codegen cache
• -c, --config <CONFIG> - Path to the TOML configuration
• -i, --ignore-missing-env-vars -Do not verify existence of environment variables

Obelisk Client

Submitting an execution

obelisk client execution submit [OPTIONS] <FUNCTION> [PARAMETERS]

Arguments:

• <FUNCTION> - Function in the fully qualified format
• [PARAMETERS]

Accepted Parameter Formats:

• JSON array string, e.g. '["first", "second", null, 1]'

• File reference prefixed with @, e.g. @file.json (file must contain a valid JSON array)

• Multiple arguments after --, e.g. -- '"first"' @secondparam.json null 1

• For functions with no parameters: [] (JSON array variant) or no arguments.

Options:

• -f, --follow - Follow the stream of events until the execution finishes
• --no-reconnect - Do not attempt to reconnect on connection error while following the status stream
• --json - Print output as JSON

Getting the current execution state

obelisk client execution get [OPTIONS] <EXECUTION_ID>

Same as with the submit command, the execution can be followed until it finishes:

• -f, --follow - Follow the status stream until the execution finishes
• --no-reconnect - Do not attempt to reconnect on connection error while following the status stream

Providing the result of a stubbed activity

obelisk client execution stub <--return-value <RETURN_VALUE>|--empty|--error> <EXECUTION_ID>

Options:

• --return-value <RETURN_VALUE> - Stub a return value encoded as JSON
• --empty - Stub an empty return value
• --error - Stub an error

Listing available components and functions

obelisk client component list [OPTIONS]

Options:

• -i, --imports - Show component imports
• -e, --extensions - Show auto-generated export extensions

Inspecting provided WASM file

This command does not connect to the server, but it outputs the exported functions of a WASM component similarily to obelisk client component list.

obelisk client component inspect [OPTIONS] <COMPONENT_TYPE> <PATH>

Arguments:

• <COMPONENT_TYPE> - One of workflow, activity_wasm, activity_stub, webhook_endpoint
• <PATH> - Path to the WASM file

Options:

• -i, --imports - Show component imports
• -e, --extensions - Show auto-generated export extensions
• -c, --convert-core-module - Attempt to convert Core WASM Module to a WASM Component

Pushing a WASM Component into an OCI Registry

This command does not connect to the server. Use docker login to authenticate against the OCI registry first.

obelisk client component push <PATH> <IMAGE_NAME>

Arguments:

• <PATH> - WASM file to be pushed
• <IMAGE_NAME> - OCI reference. Example: docker.io/repo/image:tag

Obelisk Generate

Generating extension functions

The extension WIT files of a given WASM component can be generated using:

obelisk generate extensions <COMPONENT_TYPE> <INPUT_WIT_DIRECTORY> [OUTPUT_DEPS_DIRECTORY]

Arguments:

• <COMPONENT_TYPE> - One of workflow, activity_wasm, activity_stub. No extensions are generated for webhook endpoints.
• <INPUT_WIT_DIRECTORY> - Path to the wit folder, containing the target world and possibly deps subfolder.
• [OUTPUT_DEPS_DIRECTORY] - Optional. If not set, WIT files will be written to the input directory.