Dynomate CLI

dynomate-cli runs DNML request files from a terminal, a script or a CI job.

To get the CLI, see Install the Dynomate CLI.

One runtime

The app and the CLI use one DNML runtime. They have:

• The same .dnml files.
• The same validation before any AWS call, with the same error codes.
• The same operation order, statuses, skip reasons and results.
• The same safety rules. Table deletes, truncates and endpoints in the request need confirmation in the app and approval in the CLI. Amazon Aurora DSQL operations need no confirmation or approval.

Commands

For scripts and CI jobs, see Automation and CI.

Running example

The CLI tab shows a run with requests run.

version = "1.0"name = "find-and-update-order"description = "Find the most recent order for an account, mark it reviewed, and read it back."[variables]accountId = "account#42"pageSize = "1"[defaults]profileName = "commerce-dev"[[dynamodb.query]]name = "Find recent order"tableArn = "arn:aws:dynamodb:ap-southeast-2:111122223333:table/Orders"keyConditionExpression = "accountId = :accountId"limit = "${cast(pageSize, 'integer')}"scanIndexForward = false[dynamodb.query.expressionAttributeValues]":accountId" = "${accountId}"[[dynamodb.update]]name = "Mark reviewed"dependsOn = "Find recent order"tableArn = "arn:aws:dynamodb:ap-southeast-2:111122223333:table/Orders"updateExpression = "SET #status = :status"[dynamodb.update.keyValues]accountId = "${accountId}"orderId = "${find_recent_order.items[0].orderId}"[dynamodb.update.expressionAttributeNames]"#status" = "status"[dynamodb.update.expressionAttributeValues]":status" = "REVIEWED"[[dynamodb.get]]name = "Read back"dependsOn = "Mark reviewed"tableArn = "arn:aws:dynamodb:ap-southeast-2:111122223333:table/Orders"consistentRead = true[dynamodb.get.keyValues]accountId = "${accountId}"orderId = "${find_recent_order.items[0].orderId}"

AWS credentials

The CLI uses your existing AWS sign-in. It does not sign in for you. It uses the AWS SDK credential chain with the profile from --profile in table import, or from profileName in a request. A request without a profile uses default. Profiles come from your AWS config and credentials files.

Environment variables

• AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN are read, and normally take precedence over profile credentials.
• AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE are honored.
• AWS_PROFILE does not select the profile. Use --profile or profileName.

App data directory

requests run uses the app data directory of the app for:

• Saved profile endpoints. Custom endpoints saved on a profile in the app. See Endpoints.
• Global environments. --global-env NAME loads one. See Variables and environments.
• Default exports. A dynamodb.export without a path writes to the exports folder.
• Local SQL snapshots. An export with snapshot = true registers its snapshot for the app. See Local SQL snapshots.
• Aurora DSQL network settings. The route, TLS level and trusted certificates for each cluster ARN, and the imported CA bundles in dsql-ca. Without them, the CLI uses the public endpoint and the system trust store. See Aurora DSQL network settings.
• Cluster names. The Connections: summary shows the name of each cluster that the app saved. The name comes from the Name tag of the cluster.

--collection-env reads from the collection folder, not from app data. table import uses your AWS profile, not app data. See Profiles.

Default location

Choose another directory

Set DYNO_APP_DATA_DIR to use a different directory:

• The app reads the same variable, so both can share one directory.
• If a CI run must not use saved settings, set an empty directory or no directory. Aurora DSQL operations then use the public endpoint and the system trust store.
• If the CLI cannot find a directory, requests run fails with APP_DATA_UNAVAILABLE. Set DYNO_APP_DATA_DIR.

Get help

Add --help to a command to see its subcommands and options: