Releases

Releases are tagged vX.Y.Z and publish one zip per CI build flavor ({app}-{board_type}-v{version}.zip). Each directory has a flat structure and contains the images you need, a generated README.md describing the content, and, for nRF91M1, the Serial Modem archive CI tested that night. See Release artifacts for bundle names, file descriptions, and flashing instructions.

The version is derived from conventional commit prefixes in merged commits:

Firmware built for a release embeds that version through each application's VERSION file. The CI build step overwrites VERSION from the resolved semver before compiling (without committing the change). Memfault reads it through nRF Connect SDK (CONFIG_MEMFAULT_NCS_FW_VERSION_STATIC defaults to APP_VERSION_TWEAK_STRING). The VERSION files checked into the repository are for local development only.

FOTA hardware tests on main use the same release semver as the baseline: CI passes FIRMWARE_VERSION to the Test workflow, flashes the Build artifact's merged.hex without rebuilding, then builds and deploys a patch-bumped update image (for example, 1.2.3 → 1.2.4) for OTA verification. Local runs fall back to baseline_version in .github/test/tests.yml and flash with west flash --recover.

Hardware tests use five rigs on two self-hosted runners (see .github/test/tests.yml):

Provisioning runs in parallel with the first queued test job on the separate runners. Jobs sharing a runner run one at a time; GitHub queues whichever job does not get the runner first (coredump and both FOTA jobs on the test runner, the four provisioning jobs plus LM20B FOTA on the provisioning runner).

Once the release is deployed, FOTA tests run fota poll on the DUT shell instead of waiting up to a full sync interval for the application to poll on its own. A poll that reports no update is retried, since nRF Cloud can lag behind the Memfault deployment.

DUT 3 is an nRF54LM20B DK with an nRF7002-EB II shield, wired to an nRF91 Serial Modem. Both lm20b tests use host console VCOM0 (UART30): 91m1_ppp-provision-nrf54lm20b-nrf91 flashes the plain nrf54lm20b build and runs test_cloud_provision; 91m1_ppp-provision-location-nrf54lm20b-nrf91 flashes the Wi-Fi location build and verifies Wi-Fi scan plus nRF Cloud ground-fix. Local run for plain provisioning:

export REPO_ROOT=$PWD
export TEST_JSON="$(PYTHONPATH=tests/on_target python3 -m ci.catalog load 91m1_ppp-provision-nrf54lm20b-nrf91)"
PYTHONPATH=tests/on_target pytest tests/on_target/tests/test_provision/ -c tests/on_target/tests/pytest.ini -v

Local run for the location test:

export REPO_ROOT=$PWD
export TEST_JSON="$(PYTHONPATH=tests/on_target python3 -m ci.catalog load 91m1_ppp-provision-location-nrf54lm20b-nrf91)"
PYTHONPATH=tests/on_target pytest tests/on_target/tests/test_location/ -c tests/on_target/tests/pytest.ini -v

DUT 4 is an nRF93M1 DK running 93m1_ppp, with the host console on UART20. The on-board nRF93M1 keeps the Serial Modem firmware it already has, so the test flashes only the host and captures no modem log. Local run:

export REPO_ROOT=$PWD
export TEST_JSON="$(PYTHONPATH=tests/on_target python3 -m ci.catalog load 93m1_ppp-provision-nrf93m1)"
PYTHONPATH=tests/on_target pytest tests/on_target/tests/test_provision/ -c tests/on_target/tests/pytest.ini -v

Build, compliance, and SonarCloud jobs use self-hosted-build (three runners for parallel matrix builds). Hardware tests and the test plan job use self-hosted-test on the DUT 2 rig.