Application Release Framework
Infuse-IoT includes a west workflow for automatically building application releases in a way that can be reproduced at any point in the future. Think Infrastructure-as-Code for application releases.
A given application release is a combination of the following information:
Application manifest (Board target, version, supported RPCs, etc)
Application artifacts (
.bin
,.hex
, etc)Built configuration (
autoconf.h
,CMakeCache.txt
, logs, etc)Flashing instructions (
runners.yaml
)
Building Releases
Releases are built by providing a dedicated release configuration file to
the west release-build
command, for example:
west release-build -r infuse-sdk/samples/releases/serial-nrf52840dk.yaml
Release Configuration
The .yaml
file that configures the release has the following fields:
Field |
Type |
Description |
---|---|---|
|
Relative path string |
Application folder. It can point to a file outside of the current git repository. |
|
String |
Prefix of the final folder generated by the release script. The final
output directory is |
|
String |
Complete board target the application is being built for. |
|
Relative path string |
MCUboot signing key used for the bootloader application and signing the final application. |
|
String |
List of any additional snippets to apply to the application image |
|
Relative path string |
Default network key configuration file |
|
Relative path string |
Secondary network key configuration file |
|
Boolean |
Relative path to the default network key configuration file |
|
String |
Override the application |
Note
All relative paths are relative to the release configuration file, not the current working directory.
Warning
All keys should NOT be committed to any source code repository. Instead there should be a defined
folder in the workspace root (e.g. {workspaceFolder}/keys
) that contains keys that can be referenced
by the relative path.
Release Checks
The release build process currently performs the following checks:
Validates the release configuration file against the expected schema
Validates that repositories contain no uncommitted changes or commits not present on the remote
Repository errors can be downgraded to warnings with the
--git-ignore
CLI option.Repository checks can be skipped altogether with the
--git-skip
CLI option.
Validates that the build command completes without errors
Performs a sanity check on the final application configuration:
Default signing keys
Debug port not disabled
CONFIG_MCUMGR
without OTA upgrade supportetc
Release Manifest
Once the release build has completed, a manifest file is generated inside the release folder. It contains the following information:
Field |
Type |
Description |
---|---|---|
|
String |
Name of the primary application |
|
String |
Board target from configuration file |
|
String |
System-on-Chip of the board |
|
String |
Merged bootloader + application |
|
Integer |
Unique application ID ( |
|
String |
Application version signed with |
|
Integer |
Default network ID of the application |
|
Boolean |
Application was built with sysbuild |
|
Boolean |
Application was built with Trusted-Firmware M |
|
String |
Absolute path of release configuration file |
|
String |
Commit hash of configuration file repo at build time |
|
List[String] |
List of git remotes of the repository |
|
List[String] |
List of the enabled features of the application |
|
List[String] |
List of the Remote Procedure Calls (RPC) compiled into the application |
|
List[String] |
List of the Key-Value Store keys enabled in the application |
Flashing Releases
Once built, a release can be flashed through the west release-flash
command,
for example:
west release-flash -r release-sample-serial-nrf52-1.3.7+be0cc394
Note
Hardware must have been provisioned (see Device Provisioning) before flashing a release.