Flows

• Add a deployment: a repository, a branch, one of its workflows that has a workflow_dispatch trigger, and the workflow’s inputs, read from that branch.
• Connect deployments by dragging from one to the next, and choose when each connection fires: on success, on failure (rollbacks and alerts), or always.
• Deployments with nothing before them start the flow, side by side.

Your workflows stay in your repositories. Each one needs a workflow_dispatch trigger on the branch the deployment points at; its inputs become the deployment’s fields, so a choice is a dropdown and a boolean a switch.

name: Deploy
on:
  workflow_dispatch:
    inputs:
      environment:
        type: choice
        options: [staging, production]
        required: true
      migrate:
        description: Run database migrations
        type: boolean
        default: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment }}
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh "${{ inputs.environment }}"

Each deployment starts as soon as everything before it has finished as its connection asks; otherwise it is skipped, with everything after it. The flow screen shows each box’s jobs and steps live, and a failed deployment can be retried.

Once a deployment has run a few times, its box shows the time it has left by its usual duration, and the flow and event pages say when the whole deploy should be done.

Every saved change is a new version, and each run records the version it used; the editor can restore an earlier one. Archiving a flow takes it out of the lists and stops it running, but keeps its runs and the events that deployed it, and it can be restored.