Triggers

Triggers go under on. You can give a single name, a list of names (defaults for each), or an object with options per trigger.

on: push                         # one trigger, defaults

on: [push, pull_request]         # several, defaults

on:
  push:
    branches: [main, "release/**"]
    paths_ignore: ["docs/**"]
  pull_request:
    types: [opened, synchronize, labeled]
    labels: [deploy-preview]

Trigger types

Key	Fields	Notes
push	branches, branches_ignore, tags, tags_ignore, paths, paths_ignore	Glob lists; ** is supported
pull_request	branches, paths, types, labels	types: opened, synchronize, reopened, labeled, ready_for_review, closed. GitLab merge requests and Bitbucket pull requests map to the same event
tag	tags	Sugar for push.tags
schedule	list of {cron, branch?, timezone?}	Five-field cron; IANA timezone; default UTC
manual	inputs	Run from the UI, CLI or API with typed inputs
api	inputs	API only, no UI button
pipeline	pipelines, on, branches	Fan-in from other pipelines in the same project. on: success, failure, completed
release	types, channels	Fired by the deploy domain when a release is created or promoted
webhook	secret, filter	Generic HMAC-SHA256 webhook. The payload is available as event.payload; filter is a CEL expression

The full field list, types and defaults are in the generated trigger reference.

Pipeline files on branches

The project’s stored definition of a repository pipeline is the one on the default branch. A push to another branch, a tag or a same-repository pull request runs the pipeline file as it is at that revision, so a change to .slipway/ci.yaml takes effect on the branch that makes it. A pipeline file that is new on a branch is adopted as scoped to that branch: it runs for that branch’s pushes and pull requests and shows in the list with a feature/x only badge, but it never runs from the stored copy, so it cannot drive default-branch pushes, schedules, releases or fan-in until it is merged, when the default-branch sync makes it a normal pipeline. Pull requests from forks always run the default branch’s definitions.

Inputs

manual and api triggers take typed inputs, and a top-level inputs: block supplies the defaults.

on:
  manual:
    inputs:
      version:     { type: string, required: true, description: "Semver to release" }
      dry_run:     { type: boolean, default: false }
      target:      { type: environment }
      level:       { type: choice, options: [patch, minor, major], default: patch }

Types: string, number, boolean, choice (with options), environment (a choice from the project’s environments) and secret. Read them as ${{ inputs.version }}.

From the CLI:

slipway run trigger release --input version=1.4.0 --input dry_run=true --watch

Schedules

on:
  schedule:
    - cron: "0 3 * * 1-5"       # 03:00 on weekdays
      timezone: Europe/Dublin
      branch: main

Pipeline fan-in

.slipway/promote.yaml

on:
  pipeline:
    pipelines: [api]
    on: [success]
    branches: [main]

Generic webhook

on:
  webhook:
    secret: ${{ secrets.HOOK_SECRET }}
    filter: event.payload.action == "published" && vars.REGION == "eu-west-1"

The filter is a CEL expression over event.payload (the JSON body) and vars (the project’s non-secret variables), evaluated at delivery time.

Senders POST to /hooks/generic/{pipeline_id}. The request is authenticated with an HMAC-SHA256 over the body using the trigger secret, and the signature is verified before the payload is parsed. The webhook URL and signing details are shown in the app next to the trigger. See Webhooks and events for the outbound side.

Concurrency

To stop two runs of the same pipeline colliding, or to cancel superseded runs, use concurrency:

concurrency:
  group: ${{ pipeline.name }}-${{ git.ref }}
  cancel_in_progress: true