3.1 Control Plane vs Agent Execution Plane
3.2 Project Scope Model
3.3 Data Flow: Source -> Release -> Pipeline -> Logs/Artifacts
3.4 Runtime Configuration Layers (global / project / environment)
3.5 Pipeline Execution Semantics
3.6 Release Governance Path
3.7 Rollback Architecture (Policy-driven)
3.8 Security and Trust Boundaries
3.9 State and Persistence Model
3.10 Scalability Model
3.11 Failure Modes and Recovery Patterns
3.12 Why This Architecture Works in Practice
11.6 Artifacts and Outputs
Orbnetes deployment and release orchestration documentation for operators and platform teams.
Artifacts are persisted outputs from jobs used for downstream stages or post-run inspection.
Common artifact use cases:
- pass build outputs to deploy job,
- preserve logs/reports for audit,
- store generated manifests/bundles.
Artifact model basics:
- producer job declares artifact paths,
- downstream jobs consume via
needs.<job>.artifacts.*, - metadata includes file identity details (size/hash where available).
Operational benefits:
- clearer stage contracts between jobs,
- reduced hidden filesystem coupling,
- reproducible handoff for rerun/incident analysis.
Best practices:
- keep artifact set intentional (avoid dumping entire workspace),
- define retention policy by operational need,
- include key output identifiers in logs for quick operator context.
Run/Pipeline Operational Checklist
Before declaring execution healthy:
- Graph reached expected terminal state.
- No critical job failed or was silently optional by mistake.
- Live logs confirm intended command path executed.
- Artifacts (if required) are present and usable.
- Release-linked runs reflect correct source/tag/file/environment context.
This checklist keeps runtime confidence high and reduces post-deploy surprises.