Affectionately known as warp
Basic Example:
./warp -j example.yml
warp is a jobfile parser and jinja interpreter for a requests.session backend. This allows users to define complex processes wherein data is manipulated and passed between disparate web services linking them across a single session using ansible-playbook inspired yaml files.
example.yml is one such job file. When run, warp will read the jobfile, establish session details, interpret the tasks and then run, in sequence, each of the defined tasks.
Warp uses Job Sessions ( an alias to requests.sessions) to manage certificates, auth, and other connection settings for a series of REST calls. The script creates a session (authenticated or not) in order to run the tasks evaluated therein.
A Job must have:
stubwhich serves as the base to which taskuriare joined with a '/'.taskswhich is a list of tasks to be run in the session.
A Job may have:
urlencode// set data to be urlencoded as the default payload formatauthusernamepassword
verbose// verbosity booleanvarsheaders
Basic Job Example
---
stub: "https://issues.apache.org/jira/rest/api/2"
headers:
Content-Type: "application/json"
Authorization: "basic"
auth:
username:
password:
tasks:
...
verbose: True
If the vars key is present in the job the entire dict is read into the job vars object for use.
Additionally the read_vars action works in this object. Providing a vars file via read_vars action here will initialize before starting the Pre-Flight checks
If the authentication key is present in the job but no username or pasword values are found, the script will interactively prompt for values.
The script persists in using these as the default credentials for the entire job.
If the certs key is present in the job, the script will attempt to add the following:
ca_bundle// ca bundle certificateclient// client certifcicatekey// public key
The script persist in using these settings for the entire job.
Currently there are two job options available:
verbose// turn on friendly output and show stepsurlencode// url encode the payload instead of the default json.
a task must have:
uri// The resource to be called for the taskname// The friendly display name for the taskaction// The action statement for the task
if any of there are not present, the script will bail.
a task may have:
loop// iteration statementurlencode// urlencode payload data for this task.stub_override// a URL that will override the job stub ad hoc.data// YAML formatted request payloadoutput// an output statement
Example Task
...
tasks:
- name: "Authenticate"
uri: "issue/createmeta"
action:
req: "get"
output:
write_to: "screen"
...
If the loop key is found in the task object the script will construct items via jinja interpretation. The output will be iterated through and can be referenced by iter_name
...
loop:
iter: "{% raw %}{% for issue in issues %}{{ issue.key }}{% endfor %}{% endraw %}"
iter_name: "ticket"
This will allow you to use {% raw %}{{ ticket }}{% endraw $} as a valid variable for a task
Task actions are at the core of warp functionality. All tasks must have valid action statements. Currently only two types of task are supported:
dumpreqread_vars
a dump task lets a user use jinja templating to manipulate a stored variable. When used in conjunction with an output statement this becomes fairly powerful.
...
action:
dump: "{{ query_data.nodes }}"
req tasks are the bread and butter of warp. They represent the basic REST tasks:
getputdeletepost
When run the output may be stored or manipulated with an output statement and used in another task or to generate a report.
read_vars is an object that when specified as an action, will read the contents of a yaml dict file into a variable for use.
*** Task Example ***
...
action:
read_vars:
var_file: "path/to/yaml/vars/file"
to_name: "filevars"
...
The read_vars action is unique in that it can also be called from
*** Pre-Flight Example ***
...
vars:
read_vars:
var_file: "path/to/yaml/vars/file"
to_name: "filevars"
...
Output is the directive for the output of the current task. A valid output directive must contain both a write_to and a content attribute.
There are three options for redirecting output with write_to at this time:
filescreenvar
content may be any one of:
template// directive to use a template.- additionally a valid jinja2
template_fileortemplate_strmust be provided.
- additionally a valid jinja2
raw// an alias for output.contentcontent// response.contentheaders// response.headersstatus_code// response.status_code
If no content directive is provided the default is response.content
Printing stored variable a Jinja Template string
...
output:
write_to: "screen"
content: "template"
template_str: "{% for item in items}{{ item.name }}{% endfor }"
Printing stored variable with a Jinja Template file
...
output:
write_to: "screen"
content: "template"
template_file: "templates/example.j2"
Printing task output
...
output:
write_to: "screen"
Values will be written to a file with name output["name"]. If no name is provided the script will interactively prompt for one. This method is useful for reporting
...
output:
write_to: "file"
content: "content"
name: "filename.txt"
Values stored as variables can be used in later steps with jinja templating
...
output:
write_to: "var"
content: "content"
name: "tickets"
Currently there are two job options available:
urlencode// url encode the payload instead of the default json.