AzureTRE/cli

TRE CLI

WARNING - this CLI is currently experimental

Installation

Currently, installation has only been tested within the dev container. In this context, make install-cli should work

Shell completion

The tre cli supports shell completion. To enable, run source <(_TRE_COMPLETE=bash_source tre) (or add to your profile).

Other shells are supported, see the click docs.

Login

The CLI allows you to log in using either a device code flow or client credentials flow.

Device code flow (interactive)

To log in using device code flow, run:

tre login device-code --base-url https://mytre.westeurope.cloudapp.azure.com/ 

This will prompt you to copy a device code and nagivate to https://microsoft.com/devicelogin to complete the login flow interactively.

You can specify --no-verify to disable SSL cert verification.

On versions of the API prior to '0.5.7', you will need to pass some additional parameters:

tre login device-code \
  --base-url https://mytre.westeurope.cloudapp.azure.com/ \
  --client-id <API_CLIENT_ID> \
  --aad-tenant-id <AAD_TENANT_ID> \
  --api-scope <ROOT_API_SCOPE>

NOTE: the api scope is usually of the form api://<API_CLIENT_ID>/user_impersonation

NOTE 2: When using device code flow, you need to ensure that the app registrations for the root API and any workspaces you access have device code flow enabled. (Automating this is tracked in #2709 )

Workspace authentication

Since the api scope for each workspace is different, the token returned when authenticating against the root API isn't valid against a workspace. When running interactively, the CLI will prompt you when it needs to reauthenticate for a workspace API.

You can pre-emptively get an authentication token for a workspace using the --workspace option. This can be specified multiple times to authenticate against multiple workspaces at once. You can also using --all-workspaces to get a token for all workspaces in one command.

Client credentials (service)

To log in using client credentials flow (for a service principal), run:

tre login client-credentials \
  --base-url https://mytre.westeurope.cloudapp.azure.com/ \
  --client-id <SERVICE_PRINICPAL_CLIENT_ID> \
  --client-secret <SERVICE_PRINCIPAL_CLIENT_SECRET>

You can specify --no-verify to disable SSL cert verification.

On versions of the API prior to '0.5.7', you will need to pass some additional parameters:

tre login client-credentials \
  --base-url https://mytre.westeurope.cloudapp.azure.com/ \
  --client-id <SERVICE_PRINICPAL_CLIENT_ID> \
  --client-secret <SERVICE_PRINCIPAL_CLIENT_SECRET> \
  --aad-tenant-id <AAD_TENANT_ID> \
  --api-scope <ROOT_API_SCOPE>

NOTE: the api scope is usually of the form api://<API_CLIENT_ID>/user_impersonation

Login misc

A number of the parameters on login could be removed by adding a /.metadata endpoint or similar to the API that returns the tenant id, api-scope and client id. This would likely also be useful for the UI.

General command structure

The general command structure for the CLI is:

tre plural_noun cmd
# or 
tre singular_noun id cmd

For example:

# list workspaces
tre workspaces list

## show an individual workspace
tre workspace 567f17d6-1abb-450f-991a-19398f89b3c2 show

This pattern is nested for sub-resources, e.g. operations for a workspace:

## list operations for a workspace
tre workspace 567f17d6-1abb-450f-991a-19398f89b3c2 operations list

## show an individual operation for a workspace
tre workspace 567f17d6-1abb-450f-991a-19398f89b3c2 operation 0f66839f-8727-43db-b2d6-6c7197712e36 show

Alternative structures considered

Initially, the command structure was more similar to the az CLI:

## NOTE this is an alternate syntax for illustration (i.e. not how the CLI works)
# list workspaces
tre workspace list

## show an individual workspace
tre workspace show --workspace-id 567f17d6-1abb-450f-991a-19398f89b3c2

The consistency of command grouping in this structure is nice.

However, as nested commands are added it requires editing multiple locations in the command text. So the flow when drilling down into an operation is:

## NOTE this is an alternate syntax for illustration (i.e. not how the CLI works)
# Find the workspace
tre workspace list

# Show operations for the workspace
tre workspace operation list --workspace-id 567f17d6-1abb-450f-991a-19398f89b3c2

# Show the operation
tre workspace operation show --workspace-id 567f17d6-1abb-450f-991a-19398f89b3c2 --operation-id 0f66839f-8727-43db-b2d6-6c7197712e36

This compares to: the current structure where the changes between successive commands are all at the end of the command text:

tre workspaces list
tre workspace 567f17d6-1abb-450f-991a-19398f89b3c2 operations list
tre workspace 567f17d6-1abb-450f-991a-19398f89b3c2 operation 0f66839f-8727-43db-b2d6-6c7197712e36 show

Asynchronous operations

Many operations in TRE are asynchronous, and the corresponding API endpoints return a 202 Accepted response with a Location header pointing to an operation endpoint.

The commands corresponding to these asynchronous operations will poll this resulting operation and wait until it has completed. If you don't want this behaviour, you can pass the --no-wait option.

Command output

Output formats

Most commands support formatting output as table (default), json, jsonc, raw, or none via the --output option. This can also be controlled using the TRECLI_OUTPUT environment variable, i.e. set TRECLI_OUTPUT to table to default to the table output format.

Option	Description
table	Works well for interactive use
json	Plain JSON output, ideal for parsing via jq or other tools
jsonc	Coloured, formatted JSON
raw	Results are output as-is. Useful with --query when capturing a single value
none	No output

Querying output

Most commands support JMESPath queries for the output via the --query option.

For example, to get a list of workspace IDs run tre workspaces list --query workspaces[].id.

This can be combined with --output table, e.g. tre workspaces list -o table --query "workspaces[].{id:id, name: properties.display_name}". Note that the query result must be an object with named properties (or an array of such objects)

Capturing results

Some of the commands in the CLI output progress information (e.g. tre workspace new ...).

When the CLI outputs progress information, it outputs it to stderr. The final result of the command is output to stdout.

This gives a good experience when chaining commands together, e.g.:

# Set the workspace to use
WORKSPACE_ID=567f17d6-1abb-450f-991a-19398f89b3c2
# Get the workspace etag
ETAG=$(tre workspace $WORKSPACE_ID show --query workspace._etag --output json)
# Disable the workspace (this is an asynchronous operation)
OPERATION=$(tre workspace $WORKSPACE_ID set-enabled --etag $ETAG --enable --output json)
# ^ this last command will output progress information while waiting for the operation to complete.
# And OPERATION contains the JSON describing the completed operation
# allowing you to query the status property etc
echo $OPERATION

Passing definitions

When creating new resources (e.g. workspaces), you need to pass in a definition. This can be passed in various ways: as an inline value, from a file, or from stdin.

To pass a definition inline, use the --definition option and include the JSON content, e.g. tre workspace new --definition '{"templateName":...}'

To load a definition from a file, use the --definition-file option, e.g. tre workspace new --definition-file my-worspace.json

To pass a definition via stdin, use --definition-file - (note the - to signal reading from stdin).

Reading from stdin allows you to take some interesting approaches to specifying the definition.

For example, you can use HEREDOC syntax to describe the JSON payload over multiple lines:

cat << EOF | tre workspaces new --definition-file -
{
  "templateName": "my-workspace",
  "properties": {
    "display_name": $DISPLAY_NAME,
    ...
  }
}
EOF

Or you can load the content from a file that contains embedded environment variables and use envsubst to substitute them:

cat my-workspace.json | envsubst | tre workspace new --definition file -

Overriding the API URL

When you run tre login you specify the base URL for the API, but when you are developing AzureTRE you may want to make calls against the locally running API.

To support this, you can set the TRECLI_BASE_URL environment variable and that will override the API endpoint used by the CLI.

Example usage

Creating an import airlock request

# Set the ID of the workspace to create the import request for
WORKSPACE_ID=__ADD_ID_HERE__

# Create the airlock request - change the justification as appropriate
request=$(tre workspace $WORKSPACE_ID airlock-requests new --type import --title "Ant" --justification "It's import-ant" --output json)
request_id=$(echo $request | jq -r .airlockRequest.id)

# Get the storage upload URL
upload_url=$(tre workspace $WORKSPACE_ID airlock-request $request_id get-url --query containerUrl --output raw)

# Use the az CLI to upload ant.txt from the current directory (change as required)
az storage blob upload-batch --source . --pattern ant.txt --destination $upload_url

# Submit the request for review
tre workspace $WORKSPACE_ID airlock-request $request_id submit