Pipelines

The Pipelines page gives you one overview of CI/CD activity across every connected Git provider. Instead of opening GitHub Actions, GitLab Pipelines, and Bitbucket builds separately, you see all runs in a single list -- sorted so the runs that need your attention come first.

It is a sibling of the Pull Requests view: pull requests focus on the change, pipelines focus on the CI runs for that change.

Enabling the Feature

The pipelines view is behind its own feature flag, independent of the pull request view:

1. Go to Settings → Features
2. Enable PIPELINES_VIEW
3. The new Pipelines entry appears in the sidebar navigation

You need at least one Git integration connected (GitHub, GitLab, or Bitbucket), a repository linked to a board, and an open pull/merge request with CI for runs to appear. See Prerequisites below if the page stays empty.

How Pipelines Work

Spedy does not store a separate pipeline model. Pipeline "runs" are derived on the fly from pull-request data, so the same webhook stream that powers the Pull Requests view also powers Pipelines.

The data flow:

1. Webhook in. GitHub, GitLab, or Bitbucket sends a CI event. Spedy verifies the signature and resolves the installation to the right integration.
2. Normalize. The event is converted into a provider-agnostic step and stored as a PullRequestStep row attached to its pull/merge request.
3. Live update. A pull-request:updated event is emitted to the board's real-time room, so the page updates without a refresh.
4. Group into runs. When you open the page, Spedy reads open and draft PRs plus their steps and groups the steps into runs. A re-run produces a new run because the provider issues a fresh suite/pipeline id.

Because runs are virtual, there is nothing to configure or clean up -- the view always reflects the current state of your PRs.

Run status and step status

Each run rolls up the status of its steps:

Individual steps are typed (review, check, build, test, deploy, release, artifact, other) and carry their own status (pending, running, success, failed, skipped, manual, cancelled, unknown).

Status buckets

A run is sorted into one of five buckets, selectable in the sidebar:

• Needs attention (default) -- runs that failed, are waiting on a manual gate, or are stuck (running or pending for more than 30 minutes)
• Running -- currently in progress
• Failed -- failed or partially failed
• Success -- all steps passed
• All -- every run

The default bucket is Needs attention. If all your pipelines are green, the default view is intentionally empty -- switch to All to see everything. The empty state offers a one-click shortcut for exactly this case.

What You Can Do (Read-Only View)

The Pipelines page is read-only. It surfaces CI status; it does not control your CI. You can:

• View runs as a list with a status dot, branch, author, duration, and per-step dots, or as a stage graph
• Filter by status bucket, by provider (GitHub / GitLab / Bitbucket), and by board
• Receive live updates via WebSocket as CI progresses

What you cannot do here (by design):

• Trigger, re-run, or cancel pipeline steps
• Configure CI or edit workflows
• Manage repositories or board↔repo mappings (do that under Board Settings → Integrations)

Prerequisites (Why the Page Is Empty)

A run appears only when all of the following are true:

1. PIPELINES_VIEW is enabled for your organization
2. An active Git integration exists (GitHub, GitLab, or Bitbucket)
3. The repository is linked to a board you can access
4. There is an open or draft pull/merge request on that repository
5. The PR has at least one CI step -- which, for GitHub, arrives via webhook (see below)

Data is always scoped to the boards you have access to, and the page is available to Admins and Team Members only (not Customers).

Setting Up CI Events per Provider

GitHub App: required event subscriptions

GitHub CI steps are delivered by webhooks. The Spedy GitHub App must subscribe to the right events, or the Pipelines page will stay empty even though everything else is configured.

In the GitHub App settings, under Permissions & events → Subscribe to events, enable:

Order matters: Check run and Check suite only appear in the events list once the App has the Checks: Read repository permission. Set the permission first, then the events become selectable.

The App-lifecycle events (Installation, Installation repositories, Meta/ping) are handled automatically. Events such as Workflow job, Issues, Star, or Release are not needed for pipelines.

• Webhook URL: POST https://<api-host>/api/v1/webhooks/github/app
• Signature: HMAC-SHA256 in the x-hub-signature-256 header, signed with GH_APP_WEBHOOK_SECRET

GitLab and Bitbucket

For GitLab, Spedy creates the repository webhook automatically when you link a repository to a board (push, merge request, and pipeline events). You need at least the Maintainer role in the project. See Integrations → GitLab.

For Bitbucket, the webhook is created with the repository link as well, using the token scopes listed under Integrations → Bitbucket.

Backfill and Manual Sync

Webhooks deliver CI status live, but a freshly connected repository -- or one whose webhook was added after a PR already existed -- has no history. A daily background sync at 2 AM re-imports open PRs (and PRs merged within the last 90 days) and backfills recent CI runs so the view is complete.

You can also trigger a manual sync via POST /pull-requests/sync (Admin only).

GitHub note: CI steps for GitHub are populated from check runs during this sync as well, so a repo connected after its PRs opened still fills the Pipelines view -- not only via live webhooks.

Supported Providers

All three are normalized into the same run-and-step model, so the experience is consistent regardless of provider.