Sharing Workflows
This page provides an explanation of how Commands, Pipelines, and Services workflows can be shared with your team on the CTO.ai platform, how you can run workflows from the public CTO.ai workflow registry, and how to add workflows from the public registry to your team.
If you’re new to using workflows on the CTO.ai platform, we recommend checking out our Workflows Overview document, as well as our documentation on Building and Using Workflows. Those pages will provide you with the background you need to help you better conceptualize the functionality of CTO.ai workflows.
Share a Workflow to the CTO.ai Registry (ops publish)
To run your workflow on the CTO.ai platform or share it with your team, you must first publish your workflow. By default, ops publish will build a new version of your workflow container image, prompt you for version information and a changelog message, then push your built workflow to the CTO.ai registry. To publish the workflow in the current directory, run this command in your local terminal:
For a deeper explanation of the ops publish command and its usage, have a look at the Publish a Workflow section of our workflows usage documentation.
To make a published workflow available on the public CTO.ai registry, you must set public: true in the ops.yml configuration of that workflow.
As you can see in the example above, we have inserted a public property with a value of true into our workflow’s configuration. Now, ops publish can be used as before to push your workflow update and make it accessible on the public registry.
Find a Public Workflow (ops search)
To search through all workflows that are available publicly through the CTO.ai registry, you can use ops search. When you use ops search without passing any arguments, you will be prompted to begin typing your query:
Use the arrow keys to navigate up and down through the list of available workflows, and press $inline[key,↵] (Enter) to choose a workflow. You can also directly filter your search results by passing a string as the first argument, and the displayed results will only including matching workflows:
In both cases, our search feature is only meant to help you find public workflows. After you select the workflow you wish to use, the CLI will output the ops run command you need to use to run it.
Run a Public Workflow (ops run)
You can run public workflows from the CTO.ai registry by passing the workflow name—under the namespace of the team that published the workflow—to ops run. For example, if you would like to run our tour workflow to get an overview of all the interactive functionality offered by our Commands SDKs, you can pass the fully-scoped workflow name @cto.ai/tour as the first argument of ops run:
Executing the above CLI command will download the public workflow container image to your local machine and run is locally using Docker, as it does when you run any other local workflow:
If you wish to run a workflow from the public registry on our cloud platform, it must first be added to your CTO.ai team (see next section).
Why do public workflows run locally?
On the CTO.ai platform, workflows are owned at the team level, rather than by individual users. A workflow from our public registry is one that, by definition, isn’t associated with your team.
However, when you are signed in to the ops CLI, your local environment does have the context of an active team, so the workflow can be run in the same way you would run any other local workflow (using ops run). Thus, when you run a public workflow locally, any Lifecycle Events or other types of data sent to the CTO.ai platform will be associated with the team that is active in your local environment.
Add a Workflow to Your Team (ops add)
Adding a public workflow to your CTO.ai team allows you to run that workflow on our cloud platform, rather than on your local machine. Use the ops add command with the fully-qualified workflow name as the first argument (of the form @team/workflow:version); for example, to add our tour workflow to your team, you can run the following CLI command:
Specifying the version number is optional when adding a public workflow to your team, and the most recent version available on the registry will be used by default.
List Workflows from Your Team (ops list)
All of the workflows added from the public registry or published by members of your team can be accessed with the ops list CLI command.
The interactive prompt given by this CLI command allows you to search through your team’s workflows just by typing, and you can navigate to the workflow you are seeking by using your arrow keys. Pressing the Enter key to choose a workflow will present you with an ops run command that you can copy. Like the ops search command, selecting a workflow from the results presented by ops list won’t run that workflow automatically, but it will present instructions you can follow to run it.
Remove a Workflow from Your Team (ops remove)
Removing a workflow that has been added or published to your team can be done with the ops remove command. This CLI command has one required argument: the name:version pair of the workflow you want to remove. If you pass the --all option to this command, you shouldn’t pass a version as part of the name argument, because this removes all versions of a workflow.
To remove the tour workflow added to our team in an example above, you can run the following command:
You will be prompted to confirm that you want to remove the workflow from your team, then it will be removed:
