Woodpecker CI — gated push-to-main deploy chain vs. flat, ungated PR validation
Guided views
Explore this system
Step through curated paths without changing the source diagram.
Beat
Next
ReadyChapter 01 / 01
Guided chapter
Diagram guideExplore this system
Inspecting compiled semantics
E ExportT ThemeS Style0 Reset+ Zoom in- Zoom outEsc Close
Find a node
⌕/
No matching nodes
Semantic passport
Verified source
Authored reach
Route probeChoose a start node
Pick two semantic nodes on the diagram
Choose the source, then the destination. Direction matters.
Semantic lensCompare system roles
Choose up to two semantic kinds. One reveals its real traffic; two compare only direct authored relationships.
Choose a kind to inspect its nodes and touching relationships.
Semantic radar
Building overview
Click nodeDrag to pan
Convergence Refs Guard Every Deploy
• Each deploy diffs its own refs/deployed/* ref before touching a host
• Back-to-back merges can never drop a deploy
• operation-skuld Quiet Skips green while the kit is away instead of failing red
Gated Chain vs. Flat Validation
• Push to main is a strict dependency chain: syntax-check blocks deploy-pis, deploy-pis blocks the three deploys that may run on a Pi agent
• Pull requests run every dry-run and every service check in parallel with no gate
• A PR only ever reports a diff — it never touches a real host
• validate-pr also runs fallow audit on the TypeScript services: only dead code, duplication or complexity the PR introduces fails it, inherited debt is reported, not blocked
One Build Feeds Two Static Sites
• converge-check decides first, then generate-docs and generate-continuity run before the ansible converge, chained rather than parallel to avoid a pnpm install race
• Both generators bow out when that decision is a skip, so a Quiet Skip builds nothing
• Their output ships docs.phyberapex.de (zukan) and continuity.phyberapex.de (sonae)
• validate-pr runs the same two builds so a stale generator never merges unnoticed