Pipedash
Resources

Architecture

The 11 Pipedash crates, the request flow on desktop and web, the core modules and the database tables.

Pipedash is a Rust workspace with 11 crates and a React frontend. One core library holds the logic. Two shells expose it, a Tauri app and an Axum server. Seven plugin crates talk to the CI/CD providers.

Crates

CratePurpose
pipedash-coreFramework-agnostic core library. Application services, domain types, infrastructure, plugin wiring and the event bus
pipedash-desktopThe Tauri app. Native commands, keyring token store and the Tauri event adapter
pipedash-plugin-apiThe plugin contract. The Plugin trait, the plugin registry, config and table schemas and shared types
pipedash-plugin-githubGitHub Actions plugin
pipedash-plugin-gitlabGitLab CI/CD plugin
pipedash-plugin-bitbucketBitbucket Pipelines plugin
pipedash-plugin-buildkiteBuildkite plugin
pipedash-plugin-jenkinsJenkins plugin
pipedash-plugin-tektonTekton CD plugin
pipedash-plugin-argocdArgoCD plugin
pipedash-webREST API server. Axum routes, WebSocket events and an optional embedded frontend

Request flow

The React interface talks to a shared service object. Inside Tauri it uses IPC commands. Anywhere else it uses the REST API and a WebSocket.

Web

Desktop

Tauri IPC invoke

HTTP

CoreEvent

CoreEvent

named event + JSON

type + payload

React interface

pipedash-desktop
Tauri commands

TauriEventBus

pipedash-web
REST /api/v1

WebSocketEventBus
/api/v1/ws

pipedash-core
services

Provider plugins

SQLite or PostgreSQL

Both shells call the same services in pipedash-core, so a command and its REST route behave the same way. The server nests its routes under /api/v1. The REST API page lists them.

Core modules

pipedash-core has 6 public modules and a CoreContext that wires them together.

  • application: the ProviderService, PipelineService and MetricsService, plus the RefreshManager that polls providers.
  • domain: plain types for providers, pipelines, runs, metrics and validation, with DomainError.
  • infrastructure: config loading, the database layer, the HTTP client manager, request deduplication, token stores, secret stores, storage migration and sync.
  • plugins: builds the plugin registry from the 7 plugin crates.
  • event: the CoreEvent enum, the EventBus trait and a NoOpEventBus.
  • logging: tracing setup.

The shells supply the event bus and the token store. The core stays free of Tauri and Axum types.

Storage schema

SQLx applies the migrations for the active backend, SQLite or PostgreSQL. These are the main tables.

TableContent
providersProvider name, type, config JSON, refresh interval, version for optimistic locking, last fetch time, status and error. The SQLite backend also holds encrypted_token and token_nonce here
pipelines_cacheThe last fetched pipelines per provider: name, status, repository, branch, workflow file, last run and metadata JSON
workflow_parameters_cacheTrigger form parameters per workflow, with cached_at and expires_at
run_history_cacheRun data per pipeline and run number, with a run hash
table_preferencesColumn preferences per provider and table
provider_permissionsThe permissions the token has, per provider and permission name
storage_metadataA single row with the storage backend configuration and a checksum
storage_migrationsAn audit trail of backend migrations: status, counts, backup path and timing
encrypted_tokensPostgreSQL only. Nonce and ciphertext per provider

Deleting a provider cascades to its cached pipelines, preferences and permissions.

Metrics tables

Metrics live in the main database. Older installs that kept a separate metrics file move their data into the main database at startup.

TableContent
metrics_global_configOne row with the enabled flag and the default retention. The defaults are off and 7 days
metrics_configEnabled flag and retention per pipeline
pipeline_metricsOne value per pipeline, run number, metric type and timestamp, with metadata JSON and a run hash
metrics_processing_stateThe last processed run number and time per pipeline
metrics_storage_infoOne row with the metric count, estimated size and last cleanup time

A unique index on pipeline, run number, metric type and run hash deduplicates entries. The metrics page explains what Pipedash records.