Skip to main content

[Step] Release

Overview

The release step enables publishing and managing software releases within your pipeline.

This step allows you to create software releases, attach payloads like APKs or OTA packages, and control how updates are distributed to devices.

tip

This step works with the HexDroid Update Management (OTA) feature - see the update management documentation for a complete overview of release functionality.

Syntax

steps:
- release:
# Describes metadata about this release such as version, target.
meta:
# The target is a unique **string** that identifies a specific software distribution.
# For example, generic/vsoc_x86_64/aosp_cf_x86_64_phone/userdebug/test-keys
target:
# field configuration goes here. Required. See below for more info.

# The version code is a positive **integer** that serves as the internal version number for a software build.
version_code:
# field configuration goes here. Required. See below for more info.

# The version name is a human-readable **string** of a software build.
version_name:
# field configuration. Required. See below for more info.

# List of payloads associated with this release (Optional)
payloads:
- file:
# Path to a file
# Wildcard can be used; however, only 1 match is allowed. (to avoid ambiguity)
path: out/target/product/vsoc_x86_64/boot.img
# hint to the end device what sort of payload this is,
# for example, `apk` type is applied with the help of the package manager
# where `ota` type is applied with update_engine
type: ota
# The distributed flag determines whether a payload is intended for direct delivery to end-user devices or restricted to project members.
distributed: true

# List of rollouts.
# Optional
rollouts:
- rollout:
cohort_slug: development
# `activate` or `halt`
action: activate
# number [0-100]%
percentage: 100

Configuring target / version_name / version_code

Release meta's fields (target, version_code, version_name) can be looked at dynamically during the execution or have static hardcoded configuration in the pipeline.

Static configuration

# replace <field> with either `target` / `version_name` / `version_code`
<field>: my_static_value

For dynamic configuration: the specific behavior and required subfields depend on the value you set for the mandatory type field.

type exec

Executes a single shell command and uses its standard output.

Fields:

  • type: (Required) Must be exec.
  • command: (Required) A single string representing the entire shell command to execute.
# replace <field> with either `target` / `version_name` / `version_code`
<field>:
type: exec
command: command_1

type execs

Executes a sequence of shell commands and combines their standard output.

  • type: (Required) Must be execs.
  • command: (Required) A list of strings. Each string is a shell command to be executed in the order listed. Return code must be zero.
  • separator: (Optional) A string used to join the standard output from each command. If omitted, the outputs concatenated directly.
# replace <field> with either `target` / `version_name` / `version_code`
<field>:
type: execs
separator: /
command:
- command_1
- command_2

type file

Reads data from a specified file. Can optionally extract a specific part of the content using a regular expression.

Fields:

  • type: (Required) Must be file.
  • path: (Required) A string representing the path to the file to be read.
  • regex: (Optional) A string containing a regular expression. If provided, the regex is applied to the content of the file specified by path. The value extracted will be the content matched by the first capturing group ((...)) in the regex. If the regex doesn't match or does not have a capturing group - results in failure.
# replace <field> with either `target` / `version_name` / `version_code`
<field>:
type: file
path: out/build_date.txt

Extracting a value using regex: (This example extracts the build ID from a properties file)

# replace <field> with either `target` / `version_name` / `version_code`
<field>:
type: file
path: out/dist/build.prop
regex: "ro\\.system\\.build\\.id=(.+)"

Payload files = Artifacts

All release payload files will automatically become attached to the run as CI build artifacts, so there is no need to duplicate paths to these files in artfact step.

HexDroid Step to upload CI build artifacts

Navigate to the "Artifact" tab to see all CI build artifacts.

Artifacts list grouped by AOSP lunch target

Learn more about CI artifact files here.