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:

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

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

on = {
    "push": {
        "branches": ["main", "develop"],
        "paths": ["src/**", "BUILD.rbs"],    # Only trigger on specific paths
    },
}

Pull request trigger

on = {
    "pull_request": {
        "branches": ["main"],
        "types": ["opened", "synchronize"],
    },
}

Schedule trigger (Cron)

on = {
    "schedule": {
        "cron": "0 2 * * *",   # Daily at 2 AM
    },
}

Manual trigger

on = {
    "manual": {
        "inputs": {
            "environment": {"type": "choice", "options": ["dev", "staging", "prod"]},
            "deploy": {"type": "boolean", "default": False},
        },
    },
}

Webhook trigger

on = {
    "webhook": {
        "url": "/hooks/deploy",
        "secret": "env:WEBHOOK_SECRET",
    },
}

Jobs and steps

Job configuration

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

# 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

RBS computes the dependency graph of all targets.
Changed files are mapped to their owning targets.
Only changed targets and their dependents are rebuilt and retested.

Usage

# 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:

# 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 = [...],
)

# Or enable from the command line
rbs ci --distributed

How distribution works

The platform breaks the build graph into parallelizable units.
Units are distributed to available workers on the branch server.
Results are collected and merged.
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.

Infrastructure as Code

CI/CD

Containers

Toolchains

CI/CD

Managed CI/CD

How it works

Why RBS CI?

Defining workflows

Basic workflow

Multi-stage pipeline

Triggers

Push trigger

Pull request trigger

Schedule trigger (Cron)

Manual trigger

Webhook trigger

Jobs and steps

Job configuration

Step types

Affected-only builds

How it works

Usage

Example output

DAG-based execution

Distributed execution

How distribution works

Viewing results in your editor

CI commands

​Managed CI/CD

​How it works

​Why RBS CI?

​Defining workflows

​Basic workflow

​Multi-stage pipeline

​Triggers

​Push trigger

​Pull request trigger

​Schedule trigger (Cron)

​Manual trigger

​Webhook trigger

​Jobs and steps

​Job configuration

​Step types

​Affected-only builds

​How it works

​Usage

​Example output

​DAG-based execution

​Distributed execution

​How distribution works

​Viewing results in your editor

​CI commands

Managed CI/CD

How it works

Why RBS CI?

Defining workflows

Basic workflow

Multi-stage pipeline

Triggers

Push trigger

Pull request trigger

Schedule trigger (Cron)

Manual trigger

Webhook trigger

Jobs and steps

Job configuration

Step types

Affected-only builds

How it works

Usage

Example output

DAG-based execution

Distributed execution

How distribution works

Viewing results in your editor

CI commands