Configuring Ops

There are two main files that you can configure in an Op project: ops.yml and Dockerfile.

The YAML file allows you to specify a number of options such as whether an Op is shared publicly in the CTO.ai registry and whether the Op can run remotely.

The Dockerfile allows you to specify the detailed configuration of the Op's Docker image.

ops.yml

The ops.yml file structures how your Op will run and provides information for how other users will be able to interact with it.

The run line of the yml is the entrypoint command that is run as the final step of the Dockerfile to trigger your Op.

The sample ops.yml file created by ops init for the Command template is shown below.

version: "1"

# An array of commands. You may define multiple commands, however they will
# published as separate ops.
commands:
  # Unique identifier for your op (required)
  - name: hello-command:0.1.0

    # Short description for what your op does (required)
    description: My first Command Op.

    # Determines whether this version of the op is visible to non-team-members
    public: false

    # A link to a public Github repo (e.g.: "https://github.com/cto-ai/aws") or a markdown file
    # (e.g.: "https://raw.githubusercontent.com/cto-ai/github/master/README.md").
    # The README.md will be displayed on your Op page in our Community Registry
    sourceCodeURL: ""

    # Command that is executed when op is started ("npm start",
    # "./start_script.sh", etc.) (required)
    run: node /ops/index.js

    # Provide required environment variables for your op. To pass in
    # environment variables from the host, use the $ prefix.
    # To access these variables in your code, use the language-specific API
    # (e.g. `process.env` for NodeJS).
    env:
      - "MY_ENV_VAR=$MY_ENV_VAR"
      - "MY_ACCESS_TOKEN=$MY_ACCESS_TOKEN"

    # Whitelist files and folders to be included in the published op's WORKDIR
    src:
      - Dockerfile
      - index.js
      - demo.js
      - constants
      - prompts
      - utils
      - package.json
      - .dockerignore

    # If set to `true`, binds the host's current working directory to
    # `/cwd`; default value: `false` - working directory `/ops`
    mountCwd: false

    # If set to `true`, binds the host's home directory to `/root`;
    # default value: `false`
    mountHome: false

    # Bind additional volumes; trail the string accordingly to
    # configure permissions for either read-only (:ro) or write (:w)
    # access (example: ~/tmp:/root/tmp will bind lefthand directory in
    # host to righthand directory in ops)
    bind:
      - "/tmp:/tmp"

    # Map ports for your op container
    port:
      - 3000:3000

    # Configure the output for when your op is run with `op --help` or `op -h`
    help:
      usage: "Your first hello-world op"
      arguments:
        username: "Your username"
        email: "Your email"
      options:
        build: "Build flag"
        clear: "Clears"

# An array of workflows. You may define multiple workflows, however they will
# be published as separate ops.
# Workflows are a sequence of bash commands. These can include built-in shell
# commands (eg echo, ssh), binaries (eg git, node), or other ops commands (eg
# ops run my-command). To run a local workflow, you must ensure you have all
# the dependencies installed.
workflows:
  # Unique identifier for your workflow (required)
  - name: hello-workflow:0.1.0

    # Short description for what your workflow does (required)
    description: My first Workflow Op.

    # Determines whether this version of the op is visible to non-team-members
    public: false

    # Determines whether this workflow is meant to be run on your local machine
    # or on a remote server in the cloud (experimental)
    remote: false

    # A link to a public Github repo (e.g.:
    # "https://github.com/cto-ai/example-workflow"). The README.md will be
    # displayed on your Op page in our Community Registry
    sourceCodeURL: ""

    # The sequence of steps in your workflow. Will run on your machine for
    # local (non-remote) workflows, and run dockerized in the cloud for remote
    # workflows.
    steps:
      - echo hello 1
      - echo hello 2
      - echo hello 3
    # Provide required environment variables for your op. To pass in
    # environment variables from the host, use the $ prefix.
    # To access these variables in your code, use the language-specific API
    # (e.g. `process.env` for NodeJS).
    env:
      - "MY_ENV_VAR=$MY_ENV_VAR"
      - "MY_ACCESS_TOKEN=$MY_ACCESS_TOKEN"

Dockerfile

The Dockerfile provides the build instructions to include all of the files and software packages necessary to run the Op. The sample Dockerfile created by the ops init for the Command template is shown below.

############################
# Build container
############################
FROM node:12-stretch AS dep

WORKDIR /ops

ADD package.json .
RUN npm install

ADD . .

############################
# Final container
############################
FROM registry.cto.ai/official_images/node:latest

WORKDIR /ops

COPY --from=dep /ops .

To use SDK version 2.0 or above, the final container must be built
with one of our official images. These are built on the Debian
stretch-slim image and are:

  • registry.cto.ai/official_images/base:latest, which only adds
    the needed SDK binaries in /bin to the base Debian image.
  • registry.cto.ai/official_images/node:latest, which has Node.js
    included on top of what is provided by the base image. Currently,
    this includes version 12 of Node.js.