Adds a declarative workflow system where .ontology/workflow.ncl declares
independent layers (commit-fast, ci-standard, ci-exhaustive), each with a
trigger and a set of providers. The generator materialises Woodpecker YAML,
justfile recipes, and pre-commit hook stubs from that single declaration.
Layers form a set, not a chain — no layer depends on another at the
declaration level. Woodpecker steps express fine-grained parallelism
internally (lint → test/docs/build).
Schema and catalog:
- reflection/schemas/workflow.ncl — types, contracts, provider constructors
- reflection/defaults/workflow.ncl — standard Rust/Nushell/Nickel catalog
(14 validations, 4 builds)
Generator (ore workflow generate):
- PreCommit: prints hook fragments for manual merge into .pre-commit-config.yaml
- Woodpecker: writes per-layer YAML with image selection, tool installs,
depends_on chains, and CI-aware command translation
(nu --ide-check → find+xargs; markdownlint-cli2 → node:lts image)
- Justfile: single justfiles/workflow.just aggregated from all Justfile layers
(hoisted out of per-provider loop — was writing N times, now once)
Dispatcher: ore workflow validate|list|generate|diff + ore wf v|l|gen|diff
Cargo/nextest profiles:
- .cargo/config.toml: [profile.ci-test] (debug=0, no-incremental) and
[profile.ci] (line-tables-only) — shared by test + docs hooks to reuse
.rlib artifacts; CI retains actionable backtraces
- .config/nextest.toml: ci-test (fail-fast, no retries) and ci (all failures,
one retry)
Pre-commit: nextest run with --profile ci-test --cargo-profile ci-test;
docs-links hook shares same profile to reuse artifacts
Self-application: ontoref declares its own workflow in .ontology/workflow.ncl
and the generated .woodpecker/ files are the authoritative CI definition
Migration 0014: checks workflow.ncl + both cargo and nextest profiles present
Adoption: reflection/templates/ontology/workflow.ncl stub + install_workflow
confirm in adopt_ontoref form + step 5 in adoption script template
|
||
|---|---|---|
| .. | ||
| ci-advanced.yml | ||
| ci-exhaustive.yml | ||
| ci.yml | ||
| Dockerfile | ||
| Dockerfile.cross | ||
| README.md | ||
Woodpecker CI Configuration
Pipelines for Gitea/Forgejo + Woodpecker CI.
Files
ci.yml- Main CI pipeline (push, pull requests)Dockerfile- Custom CI image with pre-installed toolsDockerfile.cross- Cross-compilation image for multi-platform builds
Setup
1. Activate Woodpecker CI
Enable Woodpecker CI in your Gitea/Forgejo repository settings.
2. (Optional) Build Custom Image
Speeds up CI by pre-installing tools (~5 min faster per run).
# Build CI image
docker build -t your-registry/ci:latest -f .woodpecker/Dockerfile .
# Push to your registry
docker push your-registry/ci:latest
# Update .woodpecker/ci.yml
# Change: image: rust:latest
# To: image: your-registry/ci:latest
3. Cross-Compilation Setup
For multi-platform builds:
# Build cross-compilation image
docker build -t your-registry/ci-cross:latest -f .woodpecker/Dockerfile.cross .
# Push to registry
docker push your-registry/ci-cross:latest
CI Pipeline (ci.yml)
Triggers: Push to main/develop, Pull Requests
Jobs:
- Lint (Rust, Bash, Nickel, Nushell, Markdown) - Parallel
- Test (all features)
- Build (release)
- Security audit
- License compliance check
Duration: ~15-20 minutes (without custom image), ~10-15 minutes (with custom image)
Triggering Pipelines
# CI pipeline (automatic on push/PR)
git push origin main
Viewing Results
- Gitea/Forgejo: Repository → Actions → Pipeline runs
- Woodpecker UI: https://your-woodpecker.instance/repos/{user}/{repo}
Differences from GitHub Actions
| Feature | GitHub Actions | Woodpecker CI |
|---|---|---|
| Matrix builds | ✅ 3 OS | ❌ Linux only* |
| Caching | ✅ Built-in | ⚠️ Server-side** |
* Multi-OS builds require multiple Woodpecker agents ** Configure in Woodpecker server settings