Ruby-native · incremental · multi-module

Build pipelines you can actually read.

Grably is a build framework on top of Rake with jobs — granular units that know their inputs and outputs, rebuild only when something changed, and stay expressive when your pipeline isn’t “just compile.”

View on GitHub How it works

Reads like Ruby. Builds like a graph.

# Rakefile — task wires jobs; jobs do the work
task :app => [:deps, :compile, :bundle]

task :compile do |t|
  out = t.javac { :srcs => '**/*.java' },
            libs: :task_deps
  t << out
end

grab ModuleCall['services/api'], as: :api

Concepts

Four ideas. No BUILD file novel.

Grably keeps the mental model small: tasks orchestrate, jobs do the work, products flow between them, and manifests remember what changed.

job

Jobs

Like Bazel targets, but in Ruby. Declare src, srcs, or opt; implement build. One job, one responsibility — compile, render, pack, upload.

product

Products

Files with a virtual destination. Globs, filters, and task buckets expand into concrete inputs — powerful { srcs: '**/*.java' } without hand-listing every path.

manifest

Incremental

Digests and per-job manifests track what changed. Unchanged jobs stay uptodate; you don’t rebuild the world because one template moved.

grab

Modules

Multi-module repos call grab across Rakefiles. Each module keeps isolation; the root graph still composes into one pipeline.

Why grably

What Grably is aiming for

A small set of principles for build pipelines that need structure without giving up Ruby’s flexibility.

Ruby when Ruby wins DSL and job logic stay in Ruby — expressive, familiar, no YAML archaeology for custom pipelines.

Inputs tracked, outputs implied Declare what goes in; let jobs produce products. No Bazel-style outs = [...] shopping list.

Lighter than Bazel Less ceremony for non-standard builds — games, assets, codegen, fat JARs, the weird middle of shipping software.

More than bare Rake Per-folder Rakefiles don’t scale; jobs, buckets, and cross-module grab do.

One job model Compile, render, or shell out — same job abstraction. Simpler graph, easier to reason about.

Fast path ahead Ruby plans the graph; a native scheduler can execute it. You keep the DSL — the engine gets sharper.

Typical pain

Rake per directory, loose deps
Bazel ceremony for custom steps
Rebuilding because you’re not sure what changed

Grably sweet spot

Monorepos with real custom processing
Teams that already think in Ruby
Pipelines between “Makefile” and “full Bazel”