The migration adds PR support, models expose PR fields, webhooks handle PR events, and tests validate it. To be honest the migrations are a bit redundant at the moment, but I'd like to handle my old deployments so it's nice(r) to have them. I *am* testing those on baremetal. Signed-off-by: NotAShelf <raf@notashelf.dev> Change-Id: I02fb4540b62d3e8159ac18b9fa63be916a6a6964 |
||
|---|---|---|
| .. | ||
| 001_initial_schema.sql | ||
| 002_add_build_system.sql | ||
| 003_production_features.sql | ||
| 004_build_outputs_and_deps.sql | ||
| 005_channels_remote_builders.sql | ||
| 006_hardening.sql | ||
| 007_branch_and_scheduling.sql | ||
| 008_user_management.sql | ||
| 009_builds_job_name_index.sql | ||
| 010_pull_request_support.sql | ||
| README.md | ||
Database Migrations
This directory contains SQL migrations for the FC database.
Migration Files
001_initial_schema.sql: Creates the core database schema including projects, jobsets, evaluations, builds, and related tables.
Running Migrations
The easiest way to run migrations is to use the vendored CLI, fc-migrate.
Packagers should vendor this crate if possible.
# Run all pending migrations
fc-migrate up postgresql://user:password@localhost/fc_ci
# Validate current schema
fc-migrate validate postgresql://user:password@localhost/fc_ci
# Create a new migration
fc-migrate create migration_name
TODO: add or generate schema overviews