latest--rev.034 - Lintel Catalog

Type	object
Schema URL	https://catalog.lintel.tools/schemas/schemastore/ops-yaml/_shared/latest--rev.034.json
Parent schema	ops-yaml

Type: object

Configuration for ops.

revision: ...
min_version: ...
forwards: ...
dependencies: ...
hooks: ...
actions: ...
options: ...

Properties

actions object

A collection of commands to run via ops. If the first argument to ops is not a builtin, ops will look for an action with that name.

For more information, see the Actions documentation on GitHub.

Default:

{
  "<action>": "<command>"
}

dependencies object

Dependencies listed in the dependencies section of ops.yml are satisfied when the ops up command is run. Some dependencies will be un-satisfied when you run ops down; e.g. services will be stopped, but packages won't be uninstalled.

This feature allows developers that are new to a project to get up and running without knowing anything about the app itself. Your ops.yml should allow a developer to ops up && ops start to run an application.

For more information, see the Dependencies documentation on GitHub.

12 nested properties

apk PackageVersioned[]

minItems=1uniqueItems=true

apt PackageVersioned[]

minItems=1uniqueItems=true

brew PackageBrew[]

Specifies that a particular brew package is needed.
Will only run if you're on a Mac.

minItems=1uniqueItems=true

cask PackageBrew[]

Specifies that a particular brew cask package is needed.
Will only run if you're on a Mac.

minItems=1uniqueItems=true

custom CommandString | object[]

Runs the given command.
Can't tell if the command needs to be run or not, so always runs it on ops up.
Therefore, the command should be idempotent.
It's also a good idea to prevent it from printing output unless it encounters an error, to keep the ops output clean.

`custom` dependencies with `up` and `down`

If a custom dependency is given as a hash, you can define separate up and down actions that are run when ops up or ops down are called, respectively.

dependencies:
	custom:
		- init file:
			up: touch file
			down: rm file

You can also define only the down command, which will execute on ops down; nothing will be executed by the dependency on ops up.

NOTE: The lines with up and down are indented past the beginning of the text init file. YAML considers - in a list to be part of the indentation, and up and down must be children of the name of the custom depdenceny, not siblings. Therefore, the following is incorrect:
dependencies:
	custom:
		- init file:
			up: touch file
			down: rm file
as it results in a Hash like:
{
	"init file" => nil,
	"up" => "touch file",
	"down" => "touch file"
}

Examples: ["bundle install --quiet",{"init file":{"up":"touch file","down":"rm file"}}]

minItems=1uniqueItems=true

dir array

minItems=1uniqueItems=true

docker array

minItems=1uniqueItems=true

gem PackageVersioned[]

minItems=1uniqueItems=true

pip PackagePip[]

This dependency ensures that the given Python package is installed.

minItems=1uniqueItems=true

snap PackageVersioned[]

minItems=1uniqueItems=true

sshkey array

minItems=1uniqueItems=true

terraform

forwards object

Sometimes a project is complex enough to split up into multiple directories. In this case, you may have ops.yml files in several places, but still want to provide easy access to these actions from the top-level directory.

With this config, ops app test will have the same effect as running ops test from the app directory. ops inf deploy will be the same as cd infrastructure && ops deploy.

When a command is forwarded to another directory, no config, secrets, or environment variables are set based on the current directory's ops.yml, and no hooks are run from the current directory's ops.yml.

If you want access to the top-level directory's config or secrets from the subdirectory, link it in the subdirectory's ops.yml:

dependencies:
  custom:
    - ln -sf ../config config

For more information, see the Forwards documentation on GitHub.

hooks object

Sometimes you want to run a command before other commands. Some examples:

You have a number of ops commands that let a developer run different test suites inside a container, and you want to make sure the container image is built beforehand.
You have some configuration that needs to happen when the software execution environment changes (e.g. going from dev to staging).

In this case, you can use the hooks feature.

For more information, see the Hooks documentation on GitHub.

1 nested properties

before CommandString[]

A series of hooks that run before actions. They do not run before builtins like up or exec.

before hooks are always executed before secrets are loaded. If you would like a before hook to have access to secrets, create an action with load_secrets: true and call the action from a before hook.

minItems=1

min_version

All of: Minimum Version, SemanticVersion string

options object

Options allow the user to change some aspects of ops behaviour.

For more information, see the Options documentation on GitHub.

14 nested properties

apt object

Affect the behaviour of apt dependencies.

Default:

{
  "use_sudo": false
}

1 nested properties

use_sudo boolean

If false, causes ops up to install the dependency's packages without sudo.

Default: true

background object

Affect the behaviour of the background builtin.

Default:

{
  "log_filename": "app.log",
  "shell": "/bin/sh"
}

3 nested properties

log_filename string

Default: "myfile.txt"

minLength=1pattern=^(?!.{256,})(?!(aux|clock\$|con|nul|prn|com[1-9]|lpt[1-9])(?:$|\.))[^ ][ \.\w\-$()+=\[\];#@~,&']+[^\. ]$

log_file_prefix

shell

completion

All of: CompletionOptions object, Deprecated

config object

Affect how configs are interpreted.

1 nested properties

path string

format=uri-reference

envdiff object

Affect the behaviour of ops envdiff.

Default:

{
  "ignored_keys": [
    "backend_config_params"
  ]
}

environment object

Statically or dynamically set global environment variables, with each key serving as a variable's name.

NOTE: The values of these variables are not interpreted by the shell before being set, so variable references like $environment will appear literally in the value of the variable.

Default:

{
  "PATH": "./bin:${PATH}"
}

environment_aliases NameString[]

Different software systems use different environment variables to determine the software execution environment. E.g. Ruby on Rails uses RAILS_ENV. Thus, ops allows the user to specify which variables should also be set to the name of the software environment.

If any environment_aliases are specified in ops.yml, ops will not change the value of $environment unless it is listed as well.

NOTE: ops will always use $environment to detect the software execution environment; environment_aliases just makes ops set other variables to match it.

Examples: ["RAILS_ENV","RACK_ENV"]

minItems=1uniqueItems=true

exec object

Affect the behaviour of ops exec.

1 nested properties

load_secrets boolean

If true, items in secrets.ejson will be loaded before execution, allowing said items to be referenced in the configuration.

Default: false

gem object

Affect the behaviour of gem dependencies.

Default:

{
  "user_install": true,
  "use_sudo": false
}

2 nested properties

user_install boolean

If true, causes ops up to run gem install --user-install ejson.

Default: false

use_sudo boolean

If false, causes ops up to install the dependency's packages without sudo.

Default: true

pip object

Affect the behaviour of pip dependencies.

Default:

{
  "command": "pip3"
}

1 nested properties

command string

The path to a pip binary, along any options you'd like to run when installing packages.

Default: "pip3"

minLength=1

secrets object

Affect how secrets are interpreted.

1 nested properties

path string

format=uri-reference

snap object

Affect the behaviour of snap dependencies.

Default:

{
  "install": true,
  "use_sudo": false
}

2 nested properties

install boolean

Unlike apt, brew, or apk, snap may be present on any Linux system, and its presence alone probably shouldn't be taken as a sign that ops should install every snap listed in dependencies. Therefore, ops will never install snaps unless the snap.install option is true.

For example, on Solus Linux, snap is necessary to install the mosquitto MQTT broker, but on Debian I would apt install mosquitto-tools instead. So both of these dependencies would be listed in the ops.yml. However, I may still have snap present; I just wouldn't want ops to install snaps unless I told it to, or it would install both the apt package and the snap.

Managing these options via hard-coded strings in ops.yml isn't the best solution, however; this file is checked in, but whether or not to install snaps should be based on environment. In the future, ops will support using env vars to set any option, based on a scheme like apt.use_sudo == $APT__USE_SUDO.

Default: false

use_sudo boolean

If false, causes ops up to install the dependency's packages without sudo.

Default: true

sshkey object

Affect how SSH keys are generated.

Default:

{
  "passphrase": "p@ssw0rd",
  "key_size": 4096
}

7 nested properties

add_keys boolean

If false, disables adding the SSH key to ssh-agent.

Default: false

key_algo string

The algorithm to generate the SSH key with.

Default: "rsa"

Values: "dsa" "ecdsa" "ecdsa-sk" "ed25519" "ed25519-sk" "rsa"

Examples: "ed25519"

key_file_comment string

An optional comment for the SSH key.

Default: "My SSH key comment"

minLength=0

key_lifetime integer

The duration, in seconds, at which the SSH key will be removed from ssh-agent.

Default: 3600

min=0

key_size integer

The size at which the SSH key will be generated.

NOTE: With the ed25519 algorithm, key_size can still be specified, but will be ignored by ssh-keygen, since all keys for that algorithm are 256 bits.

Default: 4096

Values: 512 1024 2048 4096

min=512max=4096

passphrase string

A passphrase to generate the SSH key with.

Default: "b@dP@55w0rd_tryh@rd3r"

passphrase_var string

The name of an environment variable containing the passphrase to generate the SSH key with.

Default: "SSH_KEY_PASSPHRASE"

pattern=^\w*$

up object

Affect the behaviour of the up builtin.

Default:

{
  "exit_on_error": true,
  "fail_on_error": true
}

2 nested properties

exit_on_error boolean

By default, ops up will simply continue with the next dependency even if the current dependency failed. Set this to true if you want ops up to exit on the first error it encounters.

Default: true

fail_on_error boolean

By default, ops up will exit 0 even if any dependencies failed due to errors. Set this to true if you want ops up to exit non-0 when any of the dependencies fail.

Default: true

Definitions

CommandString string | string

Deprecated

EnvList NameString[]

FileName string

LoadSecrets boolean

If true, items in secrets.ejson will be loaded before execution, allowing said items to be referenced in the configuration.

NameString string

NonEmptyString string

PackageList PackageVersioned[]

PackageBrew string

The name of a brew package. If you need to specify a version, include it after the name, delimited by an @ symbol.

Examples:

"ruby"
"openssl@"

PackagePip string

The name of a pip package. If you need to specify a version, include it after the name, delimited by ==.

Examples:

"semver"
"ruamel.yaml==0.17.26"

PackageVersioned string

The name of a package. If you need to specify a version, include it after the name, delimited by a space.

Examples:

"ruby"
"openssl 0.8.0"

Path string

PathList array

SemVer string

UseSudo

use_sudo boolean

If false, causes ops up to install the dependency's packages without sudo.

Default: true

CustomCommand string

Properties

custom dependencies with up and down

Definitions

`custom` dependencies with `up` and `down`