App Config

App config contains the settings for a Sloth CI app:

id: myapp # or "name: myapp", or "listen_point: myapp"

provider:
    github:
        owner: username
        repo: repo
        branches:
            - dev
            - staging

actions:
    - !critical touch {filename}
    - echo "The branch is {branch}" >> {filename}

params:
    filename: myfile.txt

work_dir: ~/apps/myapp

exec_timeout: 5

stop_on_first_fail: true

extensions:
    debug_logs:
        module: file_logs
        path: /var/log/myapp/
        filename: myapp_debug.log
        level: DEBUG

The config is in YAML format. When you create an app with the create command, provide the config as a path to a .yml file:

$ sci create /path/to/test.yml

When you create an app via the API, provide the config as a URL-encoded string:

$ http -f -a login:password localhost:8080 \
        action=create \
        config_string=$(cat test.yml)
HTTP/1.1 201 Created
Content-Length: 6
Content-Type: application/json
Date: Fri, 27 Nov 2015 21:39:58 GMT
Server: CherryPy/3.8.0

"test"

Listen Point

required

id: myapp # or "name: myapp", or "listen_point: myapp"

Every app has a unique URI called its listen point. If the server is running of example.com:8080, and the app’s listen point is test, the full path to the app is http://example.com:8080/test.

Listen point can contain slashes. Listen point should not start or end with a slash.

New in version 2.0.5: Aliases id and name for listen_point were added.

Provider

provider:
    github:
        owner: username
        repo: repo
        branches:
            - dev
            - staging

Although you can trigger app’s actions manually, Sloth CI’s true strength is to run actions automatically, e.g. when you push to GitHub.

A service that sends the trigger events is called a provider. To work with a certain provider, Sloth CI must have a matching validator installed. The provider param in an app config actually points to the matching validator.

See available validators and their params →

Tip

To make the app triggerable only manually, just skip the whole provider section.

Actions

actions:
    - !critical touch {filename}
    - echo "The branch is {branch}" >> {filename}

List of actions to run. Each action is a shell command. Commands are executed one by one top to bottom.

Actions can contain placeholders enclosed between curly brackets: {filename}, {branch}. The placeholders are overriden with values in this order:

  1. params from the params section
  2. params extracted by the validator
  3. params provided with the trigger command or via the trigger API method

Actions can contain stream redirects with > and >>. Actions can not contain context changes like cd or source.

If you want the whole build to fail when a particular action fails, mark the action with the !critical tag.

New in version 2.0.7: Actions can be marked critical with the !critical tag.

Params

params:
    filename: myfile.txt

Values for the placeholders in actions.

Work Dir

work_dir: ~/apps/myapp

The directory to run the actions in. By default, the actions are executed in the directory you launched Sloth CI in, e.g. work_dir=".".

Tip

The work_dir param is optional, but we highly recommend you to specify it. You want to be 100% sure your rm -rf runs.

Exec Timeout

exec_timeout: 5

The maximal allowed time in seconds for an action to run. If an action takes longer than exec_timeout seconds to execute, it’s terminated.

By default, there’s no timeout.

Stop on First Fail

Deprecated since version 2.0.7: Use critical <app-config-actions> instead.

stop_on_first_fail: true

Stop the build after the first failed action.

Default value: false, i.e. continue with the build even if some actions fail.

Extensions

extensions:
    debug_logs:
        module: file_logs
        path: /var/log/myapp/
        filename: myapp_debug.log
        level: DEBUG

App-level extension declarations.

A declaration has a unique name (debug_logs) and must contain the extension module name (file_logs). Depending on the extension, a declaration can include additional params. For example, the mentioned File Logs extension has eight params.

You can declare the same extension module multiple times under different names:

extensions:
    debug_logs:
        module: file_logs
        path: /var/log/myapp/
        filename: myapp_debug.log
        level: DEBUG
    info_logs:
        module: file_logs
        path: /var/log/myapp/
        filename: myapp_info.log
        level: INFO

No extensions are declared by default.