Hands-on: passing values between steps

Jobs run on different agents and share no filesystem. Meta-data is how a value computed in one step reaches another.

steps:
  - key: version
    command: buildkite-agent meta-data set "release-version" "$(git describe --tags)"

  - depends_on: version
    command: |
      VERSION=$(buildkite-agent meta-data get "release-version")
      echo "Releasing $VERSION"

Meta-data is scoped to the build. It is a small key/value store, not a place for files — that is what artifacts are for.

It also survives into steps that do not exist yet, which makes it the natural companion to dynamic pipelines: a generating step can record what it decided, and the steps it generates can read that decision back.

Your task

This unit is completed in your own Buildkite organisation rather than in the browser. A free organisation is enough.

Build a pipeline with two steps, keyed setter and reader. setter sets the meta-data key cert-practice to the nonce shown on this page. reader depends on it and reads the value back. Run the build, then paste its URL below.

steps:
  - key: setter
    command: buildkite-agent meta-data set "cert-practice" "<your nonce>"

  - key: reader
    depends_on: setter
    command: buildkite-agent meta-data get "cert-practice"

The step keys matter — verification looks for them by name.

The nonce ties the build to you. A build URL copied from someone else will not verify, because it will not carry your value.

Check

In a Buildkite organisation you control, run a passing build with two command steps keyed `setter` and `reader`. `setter` sets the meta-data key `cert-practice` to the value shown below; `reader` runs after it and reads the value back with `buildkite-agent meta-data get`. Paste the build URL.