By default, your op will be published to your current team's registry. You can be signed in to only one team at a time. To verify your current team you are on, run this command:
When you install the Ops CLI, your personal Team will be created. If you’re not sharing your Op, you can skip this step. However, if you are developing an Op to share with one or many groups, you can quickly create a new Team with the ops team:create command.
When you run this command, you’ll be asked to provide a team name. See the documentation for more information about managing Teams.
To begin developing a new Op, run the ops init command. Init will create a starter project locally so you can begin developing right away.
When you run this command, you’ll be asked which Op template you’d like to use (e.g., Command or Workflow)--in most cases, you’ll choose the Command template. You’ll also be asked for the name of your new Op, a short description, and which version number you would like to assign to your Op.
Note that you can chain your Ops in a Workflow, but you can also add other published Ops to your Workflows. This allows you to leverage the community to build your Workflows.
After you have run the init command, you can look through the sample project code, or start adding your own code.
Build your Op for running or testing with the ops build command. The Build command allows you to create a local Op image and test it. If you haven’t published your Op, building a local image is the only way for you to run it.
ops build [PATH]
ops build .
Run an Op from your team list or the Ops registry. When you use the ops run command, the Ops CLI will check for a local version. If there is no local image, it will check your team and the public team for a published version. If nothing is found, Run will use the path to the YAML file you’ve supplied to build the image locally and then execute the Op.
ops run path/opname
ops run .
To run a public Op that hasn't been added to your team:
ops run @teamname/opname
You can optionally supply the -b (or --build) argument to build the Op before running it.
ops run . --build
To share your work, you can publish an Op to the team you are currently on with the ops publish command. When you publish, you’ll be able to access your Op from anywhere you have the CLI installed. You can publish multiple versions of your Op to different teams.
ops publish path/opName
As part of the publishing process, you’ll be asked if you’re publishing a Command or Workflow, and for a short change log description of what is in the new version.
For a public Op, you’ll need to edit the YAML file. In ops.yml, you’ll find a field called Public. This field is False by default, but you can publish an Op publicly by setting this field to True.
Note: before publishing a new version of your Op, you will need to update the Name field in ops.yml to include the new version.
Your team registry will be published to once your image uploads successfully, you'll now find it belongs to your remote team ops:
When you run ops add, you are adding an Op from another team (e.g., your default personal Team) as a favourite under your current team. When you use ops add with a public Op, you will also see it in the list of your team's ops.
ops add opname
OPNAME should be in the format:
You can check the Ops that have been added to your Team by running ops list. To remove an Op from your team, refer to the ops remove documentation.