> ## Documentation Index > Fetch the complete documentation index at: https://docs.reasonos.com/llms.txt > Use this file to discover all available pages before exploring further. # CI/CD > Fully managed CI/CD — workers deploy automatically with every branch server, with DAG-based workflows and affected-only builds # Managed CI/CD When RBS spins up a server for your branch, **CI workers, schedulers, and job workers are deployed automatically**. There's nothing to configure — your CI pipeline runs the moment you push code. ## How it works ``` Push to branch ↓ RBS Server starts (or already running) ↓ CI workers, scheduler, build workers auto-deployed ↓ Workflows execute automatically ↓ Results stream to your code editor in real-time ``` Every branch server comes with: * **CI workers** — execute build and test jobs. * **Scheduler** — manages workflow triggers and cron-based jobs. * **Job workers** — handle long-running tasks (deployments, infrastructure changes). * **Build workers** — run the actual compilation and packaging. You never need to set up runners, configure YAML pipelines, or manage CI infrastructure. It's all included. ## Why RBS CI? | Feature | RBS CI | GitHub Actions | Jenkins | | ---------------------- | ------------------------------ | ------------------ | ------------------ | | **Setup required** | None — auto-deployed | YAML per workflow | Groovy + agents | | **Workers** | Auto-deployed per branch | Shared runners | Manual agents | | **Affected-only** | Built-in | Manual setup | Manual setup | | **Editor integration** | Native — see results in editor | Browser only | Browser only | | **Branch isolation** | Full — one server per branch | Shared environment | Shared environment | ## Defining workflows ### Basic workflow Create a `ci.rbs` file in your repository: ```python filename="ci.rbs" theme={null} load("@rbs//ci/rules.rbs", "workflow", "job", "step") workflow( name = "build_and_test", description = "Build and test all targets", on = { "push": {"branches": ["main", "develop"]}, "pull_request": {"branches": ["main"]}, }, jobs = [ job( name = "build", steps = [ step(name = "Build All", run = "rbs build //..."), ], ), job( name = "test", needs = ["build"], steps = [ step(name = "Run Tests", run = "rbs test //..."), step(name = "Check Coverage", run = "rbs coverage //..."), ], ), ], ) ``` ### Multi-stage pipeline ```python filename="ci.rbs" theme={null} workflow( name = "full_pipeline", on = {"push": {"branches": ["main"]}}, jobs = [ # Stage 1: Build job( name = "build", steps = [ step(name = "Build", run = "rbs build //..."), ], ), # Stage 2: Test (parallel — both depend on build) job( name = "unit_tests", needs = ["build"], steps = [ step(name = "Unit Tests", run = "rbs test //... --test_tag_filters=unit"), ], ), job( name = "integration_tests", needs = ["build"], steps = [ step(name = "Integration Tests", run = "rbs test //... --test_tag_filters=integration"), ], ), # Stage 3: Deploy (depends on all tests) job( name = "deploy", needs = ["unit_tests", "integration_tests"], steps = [ step(name = "Deploy", run = "rbs run //deploy:production"), ], condition = "branch == 'main'", ), ], ) ``` ## Triggers ### Push trigger ```python theme={null} on = { "push": { "branches": ["main", "develop"], "paths": ["src/**", "BUILD.rbs"], # Only trigger on specific paths }, } ``` ### Pull request trigger ```python theme={null} on = { "pull_request": { "branches": ["main"], "types": ["opened", "synchronize"], }, } ``` ### Schedule trigger (Cron) ```python theme={null} on = { "schedule": { "cron": "0 2 * * *", # Daily at 2 AM }, } ``` ### Manual trigger ```python theme={null} on = { "manual": { "inputs": { "environment": {"type": "choice", "options": ["dev", "staging", "prod"]}, "deploy": {"type": "boolean", "default": False}, }, }, } ``` ### Webhook trigger ```python theme={null} on = { "webhook": { "url": "/hooks/deploy", "secret": "env:WEBHOOK_SECRET", }, } ``` ## Jobs and steps ### Job configuration ```python theme={null} job( name = "build", needs = ["setup"], # Dependencies on other jobs condition = "branch == 'main'", # Conditional execution timeout = 300, # Timeout in seconds retry = {"max_attempts": 3, "delay": 30}, # Retry configuration env = {"NODE_ENV": "production"}, # Environment variables steps = [...], ) ``` ### Step types ```python theme={null} # Shell command step(name = "Build", run = "rbs build //...") # RBS target execution step(name = "Run App", target = "//services/api:server") # Custom script step(name = "Setup", run = """ echo "Setting up environment..." rbs workspace rbs build //tools:setup """) # Conditional step step( name = "Deploy", run = "rbs run //deploy:production", condition = "branch == 'main' and tests_passed", ) ``` ## Affected-only builds One of the most powerful CI features: instead of building and testing your entire repository, RBS intelligently determines which targets are affected by the current changes. ### How it works 1. RBS computes the dependency graph of all targets. 2. Changed files are mapped to their owning targets. 3. Only changed targets and their dependents are rebuilt and retested. ### Usage ```bash theme={null} # Build only targets affected by changes since the last commit rbs ci --affected # Build only targets affected by changes in a PR rbs ci --affected --base=origin/main ``` ### Example output ``` 🔍 Computing affected targets... 📊 Changes detected in: - services/api/Server.java - libs/common/Utils.java 🎯 Affected targets (3 of 47): //services/api:server //services/api:server_test //libs/common:utils_test ⏭️ Skipped 44 unaffected targets ✅ Build completed: 3 targets in 12s (vs ~180s for full build) ``` Results stream directly to your code editor in real-time. ## DAG-based execution CI jobs form a Directed Acyclic Graph (DAG). The platform automatically: * **Parallelizes** independent jobs across available workers. * **Orders** dependent jobs correctly. * **Fails fast** when critical jobs fail. * **Skips** downstream jobs when dependencies fail. ``` ┌─────────┐ │ build │ └────┬────┘ ┌─────┴─────┐ ┌────▼────┐ ┌────▼────┐ │ unit │ │ integ │ │ tests │ │ tests │ └────┬────┘ └────┬────┘ └─────┬─────┘ ┌────▼────┐ │ deploy │ └─────────┘ ``` ## Distributed execution The RBS platform can automatically scale workers across multiple nodes for faster builds: ```python theme={null} # In ci.rbs — enable distributed execution for a workflow workflow( name = "distributed_build", on = {"push": {"branches": ["main"]}}, execution = { "distributed": True, "strategy": "least_loaded", # or "round_robin", "tag_match" }, jobs = [...], ) ``` ```bash theme={null} # Or enable from the command line rbs ci --distributed ``` ### How distribution works 1. The platform breaks the build graph into parallelizable units. 2. Units are distributed to available workers on the branch server. 3. Results are collected and merged. 4. Artifacts are available in the unified `.rbs/` output directory. ## Viewing results in your editor CI results stream to your code editor in real-time: * **Build status** appears in the editor status bar. * **Test results** are annotated inline (pass/fail markers next to test functions). * **Build logs** are available in the RBS output panel. * **Coverage reports** highlight covered and uncovered lines directly in the editor. ## CI commands | Command | Description | | ------------------------------ | ----------------------------------------------- | | `rbs ci` | Run the default CI workflow. | | `rbs ci --workflow=NAME` | Run a specific workflow. | | `rbs ci --affected` | Run only on affected targets. | | `rbs ci --affected --base=REF` | Compute affected targets relative to a Git ref. | | `rbs ci --distributed` | Enable distributed execution. | | `rbs ci --dry-run` | Show execution plan without running. | | `rbs ci --verbose` | Show detailed execution output. |