IBM Rational Build Forge Concepts and Terminology: Objects, Workflow, and Job Execution

IBM Rational Build Forge models process automation through a small set of related objects. This reference is for DevOps engineers and build/release administrators who need a clear mental model of how access control, execution hosts, variable inheritance, project design, and job results fit together.

Originally published on 2014-07-27; fully revised and updated.

Primary source reference: IBM Build Forge v8.0 Infocenter.

How Build Forge models automation

At a high level, Build Forge defines who can act (users and groups), where work runs (servers selected at runtime), what runs (projects and steps), and what happened (job results, logs, and BOM data).

• Users and access groups: security and permissions.
• Servers and agents: execution hosts that receive work and return results.
• Collectors, manifests, selectors: runtime server characterization and selection.
• Environments: variable sets applied across server, project, and step scopes.
• Projects and steps: executable workflow and smallest unit of work.
• Jobs: running or completed project executions.

flowchart TD
    A[User starts job] --> B[Project enters queue]
    B --> C[Selector chooses server]
    C --> D[Build Forge agent receives step]
    D --> E[Apply server project and step environments]
    E --> F[Run step command]
    F --> G{Step passed}
    G -- yes --> H[Run next step]
    G -- no --> I[Mark failure and trigger notifications]
    H --> J[Job completes]
    I --> J
    J --> K[Results step log and BOM available]

Users, access groups, and roles

Users need user objects to access Build Forge. In production setups, user identity is typically integrated through LDAP, and authorization is handled by assigning users to one or more access groups with permission sets.

See also: users and access administration in the IBM docs.

Servers, selectors, and runtime placement

A server object represents a host where projects or steps can run. The host must run a Build Forge agent. Runtime placement is controlled through selectors, with collectors feeding host properties into manifests.

Related docs: server authentication, collectors, manifests, and selectors.

Environment variables and inheritance

An environment is a named set of variables. Environments can be attached at server, project, and step levels; values are combined when a step runs.

Build Forge also supports changing variable values during execution with different scopes (step-local, project-local, or permanent), and provides predefined system variables. Inheritance details: environment variable inheritance.

Projects, steps, and supporting objects

A project is an executable set of steps. Starting a project creates a job. If a project has no selector, it cannot run independently and is treated as a library.

Projects and steps can also reference notification templates, classes (for maintenance actions such as purge/archive), adaptors, and adaptor links.

Step commands and dot commands

A step is the smallest executable unit and is centered on its command content. The command can run host commands and process-engine dot commands such as .bom and .scan.

# Illustrative step command content
make all
.bom
.scanCode language: CSS (css)

Step-level behavior can be further controlled with selectors, environments, log filters, and notification templates. For pass/fail logic based on log patterns, see log filters.

Jobs, results, and audit data

A job is a running or completed project instance. After start, the process engine queues and executes it, and status is visible in the Jobs panel.

• Results: per-step execution status and runtime visibility.
• Step log: execution details, including manifest and environment context.
• Bill of Materials (BOM): traceability data for steps/manifests and additional data written through dot commands.
• Control operations: jobs can be canceled/restarted; projects can run on schedules.

See: BOM overview and job start methods.

Best practices

• Define selectors and environments early so project behavior is predictable across hosts.
• Keep environment ownership clear: server defaults, project conventions, and step-specific overrides only when needed.
• Use log filters carefully; document regex intent to avoid ambiguous pass/fail outcomes.
• Treat BOM and step logs as first-class traceability artifacts for audits and incident review.
• Periodically review access group assignments to keep least-privilege controls aligned with team roles.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.