pipelines 0.0.12

Base install

pip install pipelines

Or get the latest dev version from Github and run pip install . from within the cloned repo. Or run pip directly from git pip install git+git://github.com/Wiredcraft/pipelines@dev.

Configuration

Pipelines runs solely on files. No database is currently required. All the pipelines, the logs of each run and various temporary files are stored in the workspace.

The workspace is a folder that needs to be specified when running pipelines.

mkdir ~/pipelines_workspace

Drop your pipelines files (see format below) directly at the root of this folder.

Run standalone

Start the API with the following:

pipelines server --workspace ~/pipelines_workspace --username admin --password admin

You may want to specify a different binding IP address (default: 127.0.0.1) or different port (defaut: 8888). Refer to the pipelines --help for additional parameters.

You can now access pipelines at http://localhost:8888

Run as a daemon

Create a dedicated user to run pipelines

# Create a pipelines user
useradd -m -d /var/lib/pipelines -s /bin/false pipelines

# Create the workspace folder (optional)
mkdir /var/lib/pipelines/workspace
chown -R pipelines. /var/lib/pipelines

# Create a SSH key pair (optional)
sudo -u pipelines ssh-keygen

You may want to rely on supervisord to run the API.

# Ubuntu / Debian
apt-get install supervisor

# CentOS / RedHat (to confirm)
yum install supervisord

Copy and adapt de config file from etc/supervisor/pipelines.conf to /etc/supervisor.

# Update and reload supervisord
supervisorctl reread
supervisorctl update
supervisorctl start pipelines

Access the web interface at http://localhost:8888

Additionaly you may want to use nginx as reverse proxy as well. See sample config from etc/nginx.

Authentication

--username ADMIN_USER
--password ADMIN_PASS

GH_OAUTH_KEY=my_oauth_app_key \
GH_OAUTH_SECRET=my_super_secret \
pipelines server [--options] --github-auth=MY_ORG/MY_TEAM

Simple example

This is a very basic pipeline definition. Save it in your workspace within a .yaml file (e.g. WORKSPACE/example-pipeline.yaml). It does … nothing really useful TBH.

---
# Pipeline definitions are standard yaml and you can include comments inside

# Variables are exposed to all actions through {{ varname }} syntax.
vars:
    code_branch: dev

# Triggers define the automated ways to run the task. In addition to manual execution
# through the UI, only webhook is supported for now.
triggers:
    - type: webhook

# Actions are the steps that are run for this pipeline. The default action plugin is bash,
# but you can use others by defining the "type" field.
actions:
    - 'echo "Starting task for {{ code_branch }}"'
    - name: 'My custom name step'
      type: bash
      cmd: "echo 'less compact way to define actions'"
    - 'ls -la /tmp'

Vars

The vars section of the pipeline definition defines variables that will then be available in any of the actions.

vars:
    my_var: something

actions:
    - echo {{ my_var }}

You can then use the variables as seen above.

Note:

• You may have to quote “ your vars to respect the YAML format.

Prompts

You can prompt users to manually input fields when they run the pipeine through the web-UI. To do this add a prompt section to your pipeline definition. The prompt fields will override the variables from the vars section.

vars:
    # This is the default value when triggered and no prompt is filled (e.g. via webhook)
    my_var: default_no_prompt

prompt:
    # This is the default value when triggered via the web UI
    my_var: default_with_prompt

actions:
    # This will display:
    #    "default_no_prompt" when call via webhook
    #    "default_with_prompt" when call via UI but keeping the default
    #    "other" when call via UI and "other" is inputted by the user
    - echo {{ my_var }}

Actions

Default actions use the bash plugin and will execute command as if they were shell commands.

Other actions can be used by specifying another type. Supported types currently are:

• bash: run bash command.

• python: write inline script or run python script inside a virtualenv.

• slack: send message to Slack.

actions:
  - type: python
    script: |
      import json
      a = {'test': 'value', 'array': [1,2,3]}
      print json.dumps(a, indent=2)
  - type: python
    virtualenv:  /opt/venvs/my_env
    file: '/tmp/some_script.py'

vars:
    slack_webhook: https://hooks.slack.com/services/SOME/RANDOM/StrIng
    name: some_name

actions:
    - type: slack
      message: 'Deployment finished for project {{ name }}.'
      always_run: true

Triggers

Webhooks

If you want to run your pipeline by triggering it through a webhook you can enable it in the triggers section.

triggers:
    - type: webhook

If you open the web-UI you can see the webhook URL that was generated for this pipeline in the “Webhook” tab. You can for example configure GitHub repository to call this url after every commit.

You can access the content of the webhook content in the actions in the webhook_content variable; e.g. echo {{ webhook_content.commit_id }}

Note:

• You need to send the message via POST as application/json Content-Type.

• Documentation is coming to explain how to use the content of the data sent through the hook.