Communication Between Steps

Steps in the build pipeline can share data through three mechanisms.

build_result.json

The shared protocol between the build agent and the pipeline. The current state of build_result.json is available through the pipeline API to any Build Plugin step.

Information written by an earlier step can be accessed by later steps — for example, which step failed, how many warnings there are, and so on.

Note

The pipeline maintains build_result.json — individual steps do not write to it directly. Only Build Plugin Steps (not Script Steps) have API access to read from it.

Build artifacts

All steps can produce artifacts, and some steps depend on artifacts from earlier steps. For example:

• The Unity build step produces a Gradle project
• The Android Gradle build step relies on that output to exist

Step ordering in the pipeline definition controls execution order. It is up to each step to handle missing prerequisites — there is currently no way to express artifact dependencies in the definition, so the step should inform the user if something is missing.

Pipeline Values

Pipeline values are the primary mechanism for passing configuration to build plugins. They are loaded from YAML files referenced in the values section of the pipeline definition.

values:
  - android
  - unity

Each entry references a YAML file under Build/Pipeline/values/. Steps can request both mandatory and optional pipeline values to start their task. If a mandatory value is missing, the step will fail.

Pipeline values allow you to:

• Centralise configuration shared across multiple steps
• Vary configuration per platform or build type
• Pass build parameters from the Build Server order to individual steps