You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ops is able either to run local tasks or download them from github.
65
+
Ops is able either to run local tasks or download them from GitHub.
65
66
66
-
Tasks also can contains prerequisite binaries, and task will download them automatically and put then in the PATH.
67
+
Tasks may also contain prerequisite binaries, and `task` will download them automatically and put then in the `PATH`.
67
68
68
-
Se below for details
69
+
See below for details
69
70
70
-
### Local Taks
71
+
### Local Tasks
71
72
72
-
When you run `ops [<args>...]` it will first look for its `ops` root.
73
+
When you run `ops [<args>...]` it will first look for its `ops` root.
73
74
74
-
The `olaris` root is a folder with two files in it: `opsfile.yml` (a yaml taskfile) and `opsroot.json` (a json file with release information).
75
+
The `olaris` root is a folder with two files inside: `opsfile.yml` (a yaml taskfile) and `opsroot.json` (a json file
76
+
with release information).
75
77
76
78
The first step is to locate the root folder. The algorithm to find the tools is the following.
77
79
78
-
If the environment variable `OPS_ROOT` is defined, it will look there first, and will check if there are the two files.
79
-
80
-
Then it will look in the current folder if there is a `opsfile.yml`. If there is, it will also look for `opsroot.json`. If it is not there, it will go up one level looking for a directory with `opsfile.yml` and `opstools.json`, and selects it as the `ops` root.
81
-
82
-
If there is not a `opsfile.yml` it will look for a folder called `olaris` with both a `opsfile.yml` and `opstools.json` in it and will select it as the `ops` root.
83
-
84
-
Then it will look in `~/.ops` if there is an `olaris` folder with `opsfile.yml` and `opsroot.json`.
80
+
1. If the environment variable `OPS_ROOT` is defined, it will look there first, and will check if there are the two
81
+
files.
82
+
2. Then it will look in the current folder if there is a `opsfile.yml`. If there is, it will also look
83
+
for `opsroot.json`. If it is not there, it will go up one level looking for a directory with `opsfile.yml`
84
+
and `opstools.json`, and selects it as the `ops` root.
85
+
3. If there is not a `opsfile.yml` it will look for a folder called `olaris` with both a `opsfile.yml`
86
+
and `opstools.json` in it and will select it as the `ops` root.
87
+
4. Then it will look in `~/.ops` if there is an `olaris` folder with `opsfile.yml` and `opsroot.json`.
85
88
86
89
### Download Tasks
87
90
88
-
If the local task resolution fails, it will download its tasks from github.
91
+
If the local task resolution fails, it will download its tasks from Github.
89
92
90
-
It is the same process that you can trigger manually with the command `ops -update`.
93
+
It is the same process that you can trigger manually with the command `ops -update`.
91
94
92
95
## Where `ops` download tasks from GitHub
93
96
94
-
The repo to use is defined by the environment variable `OPS_REPO`, and defaults to `https://github.com/apache/openserverless-task`
97
+
The repo to use is defined by the environment variable `OPS_REPO`, and defaults
98
+
to `https://github.com/apache/openserverless-task`
95
99
96
-
The branch to use is defined at build time. It is noramlly named as the base version of the CLI. It can be overriden with the enviroment variable `OPS_BRANCH`.
100
+
The branch to use is defined at build time. It is noramlly named as the base version of the CLI. It can be overriden
101
+
with the enviroment variable `OPS_BRANCH`.
97
102
98
-
When you run `ops -update`, if there is not a `~/.ops/<branch>/olaris` it will clone the current branch, otherwise it will update it.
103
+
When you run `ops -update`, if there is not a `~/.ops/<branch>/olaris` it will clone the current branch, otherwise it
104
+
will update it.
99
105
100
106
## How `ops` execute tasks
101
107
102
-
`Ops` will look to the command line parameters `ops <arg1> <arg2> <arg3>` and will consider them as directory names. The list can be empty.
108
+
`Ops` will look to the command line parameters `ops <arg1> <arg2> <arg3>` and will consider them as directory names. The
109
+
list can be empty.
103
110
104
-
If there is a directory name `<arg1>` it will change to that directory. If there is then a subdirectory `<arg2>` it will change to that and so on until it finds a argument that is not a directory name.
111
+
If there is a directory name `<arg1>` it will change to that directory. If there is then a subdirectory `<arg2>` it
112
+
will change to that and so on until it finds a argument that is not a directory name.
105
113
106
-
If the last argument is a directory name, will look for a `docopts.txt`. If it is there, it will show this. If it's not there, it will execute a `ops -task -t opsfile.yml -l` showing tasks with description.
114
+
If the last argument is a directory name, will look for a `docopts.txt`. If it is there, it will show this. If it's not
115
+
there, it will execute a `ops -task -t opsfile.yml -l` showing tasks with description.
107
116
108
-
If it finds an argument not corresponding to a directory, it will consider it a task to execute,
117
+
If it finds an argument not corresponding to a directory, it will consider it a task to execute,
109
118
110
-
If there is not a `docopts.txt`, it will execute as a task, passing the other arguments (equivalent to `ops -task -t opsfile.yml <arg> -- <the-other-args>`).
119
+
If there is not a `docopts.txt`, it will execute as a task, passing the other arguments (equivalent
120
+
to `ops -task -t opsfile.yml <arg> -- <the-other-args>`).
111
121
112
-
If there is a `docopts.txt`, it will interpret it as a [`docopt`](http://docopt.org/) to parse the remaining arguments as parameters. The result of parsing is a sequence of `<key>=<value>` that will be fed to `task`. So it is equivalent to invoking `task -t opsfile.yml <arg> <key>=<value> <key>=<value>...`
122
+
If there is a `docopts.txt`, it will interpret it as a [`docopt`](http://docopt.org/) to parse the remaining arguments
123
+
as parameters. The result of parsing is a sequence of `<key>=<value>` that will be fed to `task`. So it is equivalent to
A command like `ops setup kubernetes install --context=k3s` will look in the folder `setup/kubernetes` in the ops root, if it is there, then select `install` as task to execute and parse the `--context=k3s`. It is equivalent to invoke `cd setup/kubernetes ; task install -- context=k3s`.
128
+
A command like `ops setup kubernetes install --context=k3s` will look in the folder `setup/kubernetes` in the ops root,
129
+
if it is there, then select `install` as task to execute and parse the `--context=k3s`. It is equivalent to
If there is a `docopts.txt` with a `command <name> --flag --fl=<val>` the passed parameters will be: `_name_=<name> __flag=true __fl=true _val_=<val>`.
132
+
If there is a `docopts.txt` with a `command <name> --flag --fl=<val>` the passed parameters will
Note that also this will also use the downloaded tools and the embedded commands of `ops`.
121
136
122
137
## Embedded tools
123
138
124
-
Currently task embeds the following tools, and you can invoke them directly prefixing them with `-`: (`ops -task`, `ops -basename` etc). Use `ops -help` to list them.
139
+
Currently task embeds the following tools, and you can invoke them directly prefixing them
140
+
with `-`: (`ops -task`, `ops -basename` etc). Use `ops -help` to list them.
125
141
126
142
This is the list of the tools (it could be outdated, check with `ops -help`):
127
143
@@ -164,40 +180,61 @@ Available tools:
164
180
165
181
## Environment variables for tasks
166
182
167
-
As a convenience, the system sets the following variables but you cannot override them:
183
+
As a convenience, the system sets the following variables and you **cannot override** them:
168
184
169
185
- `OPS` is the actual command you are using, so you can refer to ops itself in opsfiles as `$OPS`.
170
-
- `OPS_PWD` is the folder where `ops` is executed (the current working directory). It is used to preserve the original working directory because `ops` changes to the acutal folder where the tasks are for execution.
171
-
172
-
The following environment variables are always set and you can ovverride them.
173
-
174
-
- `OPS_CMD` is the actual command executed - defaults to the absolute path of the target of the symbolic link but it can be overriden. `OPS` will take this value.
175
-
- `OPS_VERSION` can be defined to set ops's version value. It is useful to override version validations when updating tasks (and you know what you are doing). Current value is defined at build time and stored in sources in version.txt
176
-
- `OPS_HOME` is the home dir, defaults to `~/.ops`
177
-
- `OPS_REPO` is the github repo where `ops` downloads its tasks. If not defined, it defaults to `https://github.com/apache/openserverless-task`.
178
-
- `OPS_BRANCH` is the branch where `ops` looks for its tasks. The branch to use is defined at build time and it is ususally the base version (without the patch level). Check `branch.txt` for the current value
179
-
- `OPS_ROOT` is the folder where `ops` looks for its tasks. If not defined, if will follow the algirithm described before to finding it locally. Otherwise download it from github, git clones or git updates the `$OPS_REPO` in the `$OPS_BRANCH` and store it is `$OPS_HOME/$OPS_BRANCH/olaris`
180
-
181
-
- `OPS_BIN` is the folder where `ops` looks for binaries (external command line tools). If not defined, it defaults to `~/.ops/{{.OS}}-{{.ARCH}}/bin`. All the prerequisites are downloaded in this directory. It is automatically added to the PATH at the beginning when executing opsfiles.
182
-
- `OPS_TMP` is a temporary folder where you can store temp files - defaults to `~/.ops/tmp`
183
-
- `OPS_APIHOST` is the host for `ops -login`. It is used in place of the first argument of `ops -login`. If empty, the command will expect the first argument to be the apihost.
184
-
- `OPS_USER` is set the username for `ops -login`. The default is `nuvolaris`. It can be overriden by passing the username as an argument to `ops -login` or by setting the environment variable.
185
-
- `OPS_PASSWORD`: set the password for `ops -login`. If not set, `ops -login` will prompt for the password. It is useful for tests and non-interactive environments.
186
-
- `OPS_ROOT_PLUGIN` is the folder where `ops` looks for plugins. If not defined, it defaults to the same directory where `ops` is located.
187
-
- `OPS_PORT` is the port where `ops` will run embedded web server for the configurator. If not defined, it defaults to `9678`.
188
-
- `OPS_OLARIS` holds the head commit hash of the used olaris repo. If it is a local version its value is `<local>`. You can see the hash with `ops -info`.
186
+
- `OPS_PWD` is the folder where `ops` is executed (the current working directory). It is used to preserve the original
187
+
working directory because `ops` changes to the acutal folder where the tasks are for execution.
188
+
189
+
The following environment variables are always set and you **can override** them.
190
+
191
+
- `OPS_CMD` is the actual command executed - defaults to the absolute path of the target of the symbolic link but it can
192
+
be overriden. `OPS` will take this value.
193
+
- `OPS_VERSION` can be defined to set ops's version value. It is useful to override version validations when updating
194
+
tasks (and you know what you are doing). Current value is defined at build time and stored in sources in version.txt
195
+
- `OPS_HOME` is the home dir, defaults to `~/.ops`
196
+
- `OPS_REPO` is the github repo where `ops` downloads its tasks. If not defined, it defaults
197
+
to `https://github.com/apache/openserverless-task`.
198
+
- `OPS_BRANCH` is the branch where `ops` looks for its tasks. The branch to use is defined at build time and it is
199
+
usually the base version (without the patch level). Check `branch.txt` for the current value
200
+
- `OPS_ROOT` is the folder where `ops` looks for its tasks. If not defined, if will follow the algorithm described
201
+
before to finding it locally. Otherwise download it from GitHub, git clones or git updates the `$OPS_REPO` in
202
+
the `$OPS_BRANCH` and store it is `$OPS_HOME/$OPS_BRANCH/olaris`.
203
+
- `OPS_BIN` is the folder where `ops` looks for binaries (external command line tools). If not defined, it defaults
204
+
to `~/.ops/{{.OS}}-{{.ARCH}}/bin`. All the prerequisites are downloaded in this directory. It is automatically added
205
+
to the PATH at the beginning when executing opsfiles.
206
+
- `OPS_TMP` is a temporary folder where you can store temp files - defaults to `~/.ops/tmp`
207
+
- `OPS_APIHOST` is the host for `ops -login`. It is used in place of the first argument of `ops -login`. If empty, the
208
+
command will expect the first argument to be the apihost.
209
+
- `OPS_USER` is set the username for `ops -login`. The default is `nuvolaris`. It can be overriden by passing the
210
+
username as an argument to `ops -login` or by setting the environment variable.
211
+
- `OPS_PASSWORD`: set the password for `ops -login`. If not set, `ops -login` will prompt for the password. It is useful
212
+
for tests and non-interactive environments.
213
+
- `OPS_ROOT_PLUGIN` is the folder where `ops` looks for plugins. If not defined, it defaults to the same directory
214
+
where `ops` is located.
215
+
- `OPS_PORT` is the port where `ops` will run embedded web server for the configurator. If not defined, it defaults
216
+
to `9678`.
217
+
- `OPS_OLARIS` holds the head commit hash of the used olaris repo. If it is a local version its value is `<local>`. You
218
+
can see the hash with `ops -info`.
189
219
190
220
## Special purpose environment variables
191
221
192
-
The following variables have a special purpose and used for test and debug
193
-
194
-
- `DEBUG` if set enable debugging messages
195
-
- `TRACE` when set gives mode detailes tracing informations, also enable DEBUG=1
196
-
- `EXTRA` appends extra arguments to the task invocation - useful when you need to set extra variables with a docopts active.
197
-
- `__OS` overrides the value of the detected operating system - useful to test prereq scripts
198
-
- `__ARCH` overrides the value of the detected architecture - useful to test prereq scripts
199
-
- `OPS_RUNTIMES_JSON` is used for the values of the runtimes json if the system is unable to read in other ways the current runtimes json. It is normally compiled in when you buid from the current version of the runtimes.json. It can be overriden
200
-
- `OPS_COREUTILS` is a string, a space separated list, which lists all the commands the coreutils binary provided. It should be kept updated with the values of the current version used. It can be overriden
201
-
- `OPS_TOOLS` is a string, a space separated list, which lists all the commands provided as internal tool by the ops binary. It shold be kept updated with the current list of tools provided. It can be overriden defining externally
202
-
- `OPS_NO_DOCOPTS` can be defined to disable docopts parsing. Useful to test hidden tasks. When this is enabled it also shows all the tasks instead of just those with a description.
203
-
- `OPS_NO_PREREQ` disable downloading of prerequisites - you have to ensure at least coreutils is in the path to make things work
222
+
The following variables have a special purpose and used for test and debug:
223
+
224
+
- `DEBUG` if set enable debugging messages.
225
+
- `TRACE` when set gives mode detailes tracing informations, also enable `DEBUG=1`.
226
+
- `EXTRA` appends extra arguments to the task invocation - useful when you need to set extra variables with a docopts
227
+
active.
228
+
- `__OS` overrides the value of the detected operating system - useful to test prereq scripts.
229
+
- `__ARCH` overrides the value of the detected architecture - useful to test prereq scripts.
230
+
- `OPS_RUNTIMES_JSON` is used for the values of the runtimes json if the system is unable to read in other ways the
231
+
current runtimes json. It is normally compiled in when you buid from the current version of the runtimes.json. It can
232
+
be overriden
233
+
- `OPS_COREUTILS` is a string, a space separated list, which lists all the commands the coreutils binary provided. It
234
+
should be kept updated with the values of the current version used. It can be overriden
235
+
- `OPS_TOOLS` is a string, a space separated list, which lists all the commands provided as internal tool by the ops
236
+
binary. It shold be kept updated with the current list of tools provided. It can be overriden defining externally.
237
+
- `OPS_NO_DOCOPTS` can be defined to disable docopts parsing. Useful to test hidden tasks. When this is enabled it also
238
+
shows all the tasks instead of just those with a description.
239
+
- `OPS_NO_PREREQ` disable downloading of prerequisites - you have to ensure at least coreutils is in the path to make
0 commit comments