Templating & Variables

Overview

FirmwareCI provides two mechanisms for dynamic content:

Templates: Resolved at test start from external sources. Syntax: [[category.identifier]]

Variables: Defined and modified during test execution. Syntax: {{ variable_name }}

Template Syntax

Format

[[category.identifier]]

Category: Template source (input, attributes, reservation, storage, secrets, ssh-keys)

Identifier: Specific value name. Allowed characters: a-z, A-Z, 0-9, _, -

Template Categories

CategorySourceResolution TimeRequiredTypical Use Cases
inputJob trigger parametersJob startYes (if referenced)Firmware binaries, test parameters
attributesDUT configurationTest startYes (if referenced)Host addresses, device IDs, credentials
reservationExternal reservation systemTest startYes (if configured)Dynamic IDs, allocated resources
storageStorage configurationTest startYes (if referenced)Tool paths, test data locations
secretsWorkflow secretsTest startYes (if referenced)API tokens, passwords
ssh-keysOrganization SSH keysTest startYes (if referenced)SSH authentication

Input Templates

Syntax: [[input.InputName]]

Description: References dynamic data provided when triggering workflows. All referenced inputs must be supplied at job submission or the job will not start.

Example:

pre-stage:
  - cmd: dutctl
    parameters:
      args: [write, "[[input.Binary]]"]

See Templating guide for examples.

Attribute Templates

Syntax: [[attributes.AttributeName]]

Description: References values from DUT configuration. Defined in dut.yaml files.

Example:

parameters:
  host: "[[attributes.Host]]"

See DUT Configuration for schema details.

Reservation Templates

Syntax: [[reservation.AttributeName]]

Description: References dynamic data from external reservation systems. Populated by the configured reservation system prior to test execution.

Configuration: Set reservation-system field in dut.yaml to enable external reservation integration.

See DUT Configuration for reservation system setup.

Storage Templates

Syntax: [[storage.StorageName]]

Description: References paths to storage items. Resolves to the mounted path where the storage is available during test execution.

Example:

parameters:
  source: "[[storage.tools]]/binary"
  destination: /tmp/binary

See Storage Configuration and Storage guide.

Secret Templates

Syntax: [[secrets.SecretName]]

Description: References sensitive data stored in workflow configuration. Secrets are encrypted and only accessible during test execution.

Example:

parameters:
  token: "[[secrets.APIToken]]"
  url: "[[secrets.ServiceURL]]"

See Secrets guide for managing secrets.

SSH Key Templates

Syntax Reference

TemplateDescriptionReturns
[[ssh-keys.key_name]]Private key path (default)/path/to/key_name
[[ssh-keys.key_name.private]]Private key path (explicit)/path/to/key_name
[[ssh-keys.key_name.public]]Public key path/path/to/key_name.pub
[[ssh-keys.default]]Instance default private key/path/to/default
[[ssh-keys.default.private]]Instance default private key/path/to/default
[[ssh-keys.default.public]]Instance default public key/path/to/default.pub

Description

References organization-level SSH keys mounted into test containers. Keys are automatically discovered if identity_file is not specified in transport configuration.

Usage

transport:
  proto: ssh
  options:
    host: "[[attributes.Host]]"
    user: root
    identity_file: "[[ssh-keys.deploy_key]]"

Auto-Discovery

If identity_file is omitted, all available organization SSH keys are tried automatically:

transport:
  proto: ssh
  options:
    host: "[[attributes.Host]]"
    user: root
    # No identity_file - uses auto-discovery

See SSH Key Management for key setup and management.

YAML Anchors (Defaults)

Syntax

Define anchors under the defaults keyword:

defaults:
  name: &anchor_name
    key: value

Reference anchors using *anchor_name:

field: *anchor_name

Description

YAML anchors reduce redundancy by defining reusable configuration blocks. FirmwareCI supports standard YAML 1.2 anchor and alias syntax.

Usage

defaults:
  transport: &transport
    proto: ssh
    options:
      host: "[[attributes.Host]]"
      user: root

stages:
  - name: Test
    steps:
      - cmd: cmd
        transport: *transport
        parameters:
          executable: uname

See YAML specification for complete syntax.

Variables

Syntax

Declaration:

variables:
  var_name: "initial_value"

Assignment (in step):

parameters:
  variable: "var_name"

Reference:

args: ["{{ var_name }}"]

Description

Variables store and reuse dynamic data during test execution. Variables can be:

  • Declared globally at test file start
  • Assigned by step output during execution
  • Referenced in any subsequent step

Variable Naming

Allowed characters: a-z, A-Z, 0-9, _

Scope

Variables are scoped to the test file. All stages and steps within the test can access defined variables.

Usage

variables:
  tmpdir: "/tmp/default"

stages:
  - name: Create and Use Directory
    steps:
      - cmd: cmd
        name: Create directory
        parameters:
          executable: mktemp
          args: ["-d", "/tmp/test.XXXXXX"]
          variable: "tmpdir"

      - cmd: cmd
        name: List directory
        parameters:
          executable: ls
          args: ["{{ tmpdir }}"]

Variable Assignment

Commands that support variable assignment capture stdout and store it in the specified variable. Check individual command documentation in Test Step Commands for variable support.

Template Resolution Order

Templates are resolved in this order during test execution:

  1. Pre-execution: input, attributes, reservation, secrets, storage, ssh-keys templates resolved before test starts
  2. During execution: Variables resolved at each step based on current state
  3. YAML anchors: Expanded during YAML parsing before template resolution