[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.
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 beexec
.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 beexecs
.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 befile
.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 bypath
. 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.
Navigate to the "Artifact" tab to see all CI build artifacts.
Learn more about CI artifact files here.