...
Each command can be available in different versions like v1
, v2
, v3
, and so on. This is to support downwards compatibility in pipeline scripts. This way a newer version of a command will not break old pipeline code since it can be specified in a pipeline which exact command version to be useduse.
Which commands are available in which versions can be found in the commands reference docs.
...
Code Block | ||
---|---|---|
| ||
pipeline: - log:v3: message: "Hello World!" |
Here, we use version v4
of thelog
command log
:
Code Block | ||
---|---|---|
| ||
pipeline: - log:v4: message: "Hello World!" |
...
Instead of defining the version for each command, you can also set it globally for all commands of a pipeline using the header version
. ExampleFor example:
Code Block | ||
---|---|---|
| ||
headers: version: v4 pipeline: - log: message: "Hello World!" |
...
In case you combine the header version
with the local version on a command, the local one wins:
...
In case you specify a version like v5
, for example, it will be tried attempt to load the command with this exact version. In case no such command with this version exists, the next lower version will be looked up, like v4
for example. If no command with this version exists, the next lower version v3
is tried, and so on until v1
is reached which is the most minimal version and must be available for any existing command.
...
If no version is specified, by default the latest available version is used, which is the highest available version of each commandnumber of an command. Lets assume you have a command log
available in versions v1
, v2
and v3
. Using the keyword latest
here would pick-up the version v3
and use it:
Code Block | ||
---|---|---|
| ||
pipeline: - log: message: "Hello World!" |
...
Code Block | ||
---|---|---|
| ||
headers: version: latest pipeline: - log: message: "Hello World!" |
Is the same as:
Code Block | ||
---|---|---|
| ||
pipeline: - log:v3: message: "Hello World!" |