Write remote scripts

What a remote script needs in order to run, and how its variables become action inputs

A remote script can be written in any scripting language, as long as that language is installed on the target server and allowed to run there. On Windows, the execution policy must permit the script. On *nix, the script must begin with a shebang line.

Shebang lines

A bash script starts with one of these:

#!/bin/bash

or the more portable form, which resolves bash through env:

#!/usr/bin/env bash

The portable form requires the interpreter to be on the PATH of the target server.

A shebang can also pass arguments to the interpreter, and this works for PowerShell as well as for *nix shells. It is the usual way to raise execution privileges at run time:

#!C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy UnRestricted -File

Parameterize a remote script

Whenever a script’s content changes, either because you upload a new file or because the file at the specified URL changes, Cloud Management Platform (CMP) scans it for template variables of the form {{ variable }} and creates an action input for each one it finds.

An action input that accepts multiple values needs a join filter so CMP knows how to format them. To pass a list as space-separated arguments:

echo {{ arguments|join:' ' }}

The Commandline args attribute can also be parameterized, but parameterized command line arguments are not automatically associated with action inputs. See Action input parameters for how generated action inputs work, and Action context for the objects available to a remote script in each context.

Output and return codes

CMP expects a script to return a zero exit code on success. A non-zero code, or a script that fails to execute at all, marks the job as failed.

Anything the script writes to output is recorded in the job progress messages and the job log file.