Templates and reusable steps

Reusable steps

A reusable step is described by a step.yaml manifest and distributed as an OCI artifact (an image or a JS bundle), or lives in your repository.

name: docker-build
description: Build and push an OCI image
inputs:
  context: { type: string, default: "." }
  push: { type: boolean, default: true }
outputs:
  digest: { description: Image digest }
runs:
  using: docker            # docker | node22 | composite
  image: ghcr.io/slipway/steps/docker-build:1

Use it with uses: owner/name@ref. Pin to a version or a digest. For local steps use uses: ./.slipway/steps/foo.

Org-level templates

Templates are plain YAML with parameters: and ${{ parameters.x }}. Versions are immutable once published, so a pipeline that pins @v1 cannot change under you.

# template org/go-service@v1
parameters:
  go_version: { type: string, default: "1.27" }
jobs:
  - name: test
    container: { image: "golang:${{ parameters.go_version }}" }
    steps:
      - uses: slipway/checkout@v1
      - run: go test ./...

Use a template at step, job or stage level:

steps:
  - template: org/lint@v1
    with: { paths: ./... }

Inheriting a whole pipeline

version: 1
extends: org/base-pipeline@v2
# override by name
jobs:
  - name: test
    steps:
      - run: make test

With extends, name is optional and stages/jobs replace or add to the base by name. Use this for an organisation-wide golden path while letting teams override a single job.

Governance

Templates are how a platform team gives developers safe defaults: a base pipeline with approved scanning and signing jobs, with per-service overrides. Combine with environment policy gates to require that a release was produced by a pipeline that extends the approved base.